Performance/Fenix

Performance can be thought in terms of "Offense" – the changes that you make to actively improve performance – and "Defense" – the systems you have in place to prevent performance regression's (this offense/defense idea from this blog post).

Defense: discouraging use of expensive APIs

In some cases, we want to discourage folks from using expensive APIs such as runBlocking. As a first draft solution, we propose a multi-step check:

1. Compile-time check throughout the codebase: write a code ownered test asserting the number of references to the API.
   1. Question: given the lint rule, should we just count the number of `@Suppress` for this?
   2. Question: would it help if this was an annotation processor on our lint rule and we look for @Suppress?
2. Run-time check on critical paths: wrap the API and increment a counter each time it is called. For each critical path (e.g. start up, page load), write a code ownered test asserting the number of calls to the API.
   1. Question: is this too "perfect is the enemy of the good?"
3. Add lint rule to discourage use of the API. This overlaps with the compile-time check, however:
   1. We can't just use the compile-time check because in the best case it'll only run before the git push – it won't appear in the IDE – and the feedback loop will be too long for devs
   2. We can't just use the lint rule because it can be suppressed and we won't notice

App start up

Defense

The FE perf team has the following measures in place to prevent regressions:

• Show long term start up trends with Nightly performance tests (note: these are not granular enough to practically identify & fix regressions)
• Prevent main thread IO by:
  • Crashing on main thread IO in debug builds using StrictMode (code)
  • Preventing StrictMode suppressions by running tests that assert for the current known suppression count. We are Code Owners for the tests so we will have a discussion if the count changes (code)
• Code added to the start up path should be reviewed by the performance team:
  • We are Code Owners for a few files

WIP

We're working on adding:

• Regression testing per master merge (issue)
• Prevent main thread IO with:
  • Static analysis to prevent runBlocking, which can circumvent StrictMode (issue)
• Code added to the start-up path should be reviewed by the performance team:
  • We're investigating other files that can be separated so we can be code owners for the start up parts (issue)
• Minimize component initialization with:
  • Avoid unnecessary initialization (issue)
• Prevent unnecessarily expensive UI with:
  • NestedConstraintLayout static analysis (issue)

Offense

TODO: improve this section, if useful (let us know if it is)

We're keeping a list of the biggest known performance improvements we can make. Also, we have a startup improvement plan.