Confirmed users
975
edits
Performance/Fenix/Best Practices: Difference between revisions
→Use the profiler is to understand problems, not assert their absence
No edit summary |
|||
| Line 21: | Line 21: | ||
The profiler is useful for understanding what might cause a perf problem but '''it's imperfect for understanding if a perf problem exists or not.''' For example, if you've made a code change with the intention of improving performance, you may notice that the problem point is gone in your profile. Success, right? Maybe not: '''the code change may have moved the performance problem elsewhere''' and it's easy to overlook this in the profiler view. For example, perhaps you removed a long call to load <code>SharedPreferences</code> but the next call to <code>SharedPreferences</code> increases in duration to compensate and start up is just as slow. | The profiler is useful for understanding what might cause a perf problem but '''it's imperfect for understanding if a perf problem exists or not.''' For example, if you've made a code change with the intention of improving performance, you may notice that the problem point is gone in your profile. Success, right? Maybe not: '''the code change may have moved the performance problem elsewhere''' and it's easy to overlook this in the profiler view. For example, perhaps you removed a long call to load <code>SharedPreferences</code> but the next call to <code>SharedPreferences</code> increases in duration to compensate and start up is just as slow. | ||
To see if a code change creates a perf regression or improvement, you should '''ideally run a known benchmark''' – i.e. a duration measurement from a start point to a stop point – and see how performance changes before and after your code change. With benchmarks, | To see if a code change creates a perf regression or improvement, you should '''ideally run a known benchmark''' – i.e. a duration measurement from a start point to a stop point – and see how performance changes before and after your code change. With benchmarks, there's no possibility to overlook things like in the profiler. If you don't have a benchmark, you can create your own with timestamp logs, though it should be done carefully to ensure the measurements are consistent – writing good benchmarks is hard. | ||
== Don't guess, measure. == | == Don't guess, measure. == | ||
TODO: https://firefox-source-docs.mozilla.org/performance/bestpractices.html#dont-guessmeasure | TODO: https://firefox-source-docs.mozilla.org/performance/bestpractices.html#dont-guessmeasure | ||