Confirmed users
975
edits
Performance/Fenix/Best Practices: Difference between revisions
Performance/Fenix/Best Practices (view source)
Revision as of 16:03, 17 August 2021
, 17 August 2021→Avoid blocking on the main thread: Write "good enough" section
(Add profiler section) |
(→Avoid blocking on the main thread: Write "good enough" section) |
||
| (6 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
This guide will help Fenix developers working on front-end code (i.e. Kotlin/Java) produce code which is as performant as possible – not just on its own, but in terms of its impact on other parts of Firefox. Always keep in mind the side effects your changes may have, from blocking other tasks, to interfering with other user interface elements. | This guide will help Fenix developers working on front-end code (i.e. Kotlin/Java) produce code which is as performant as possible – not just on its own, but in terms of its impact on other parts of Firefox. Always keep in mind the side effects your changes may have, from blocking other tasks, to interfering with other user interface elements. This page is inspired by [https://firefox-source-docs.mozilla.org/performance/bestpractices.html desktop Firefox's front-end perf best practices]. | ||
== Avoid blocking on the main thread == | == Avoid blocking on the main thread == | ||
TODO | Most performance problems are about the algorithm: does this need to happen right here? IO – disk or network – is one of the longest running tasks performed in common Android applications. A typical IO operation is long enough for the user to perceive it. To avoid slowing down the user for too long, don't do IO on the main thread! StrictMode should warn you if you try to do this (though it's only enabled for start up currently). TODO | ||
== Think carefully before optimizations using background threads == | == Think carefully before optimizations using background threads == | ||
| Line 19: | Line 19: | ||
== Use the profiler is to understand problems, not assert their absence == | == Use the profiler is to understand problems, not assert their absence == | ||
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, there's less opportunity to overlook "the potential fix moved the perf problem elsewhere" 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. == | |||
TODO: https://firefox-source-docs.mozilla.org/performance/bestpractices.html#dont-guessmeasure | |||
== Coroutines, posted events, & delaying UI events == | |||
How problematic is this in practice? Worth writing this section? | |||
Also the UI churn associated with it? (less impactful except time to fully drawn?) | |||