Changes

Jump to: navigation, search

Performance/Fenix

2,137 bytes added, 00:52, 24 February 2021
Performance testing: Prepend critical flows and add start up details
== Critical flows ==
Any areas of the app where users might retain significantly less if performance regressed are considered to be '''critical flows'''. For example, if pages took twice as long to load, we might expect to see some users stop using the app.
 
When analyzing a critical flow for performance issues, it's essential to know what code is relevant. The '''endpoints''' tell you when the flow starts and stops and the '''bottleneck''' is the resource (e.g. CPU, disk) that is maxed out and preventing the device from reaching the flow's final endpoint sooner (e.g. removing expensive computation may not improve perf if the bottleneck is the desk).
 
Our critical flows, their endpoints, and their bottlenecks are listed below.
 
=== Start up ===
There are a few different types of start up: see [[#Terminology|Terminology]] for clarifications.
 
* COLD MAIN (to homescreen) start: the endpoints are process start and visual completeness (i.e. the homescreen is fully drawn). We believe the bottleneck is the main thread. A possibly important event for perceived performance is when the first frame is drawn
** Neither endpoint is available in the profiler. Surrogates are <code>Application.onCreate</code> or <code>*Activity.onCreate</code> or the first frame is drawn (the last two have profiler markers)
* WARM MAIN (to homescreen) start: the endpoints are <code>IntentReceiverActivity.onCreate</code> and visual completeness. See COLD MAIN for the bottleneck and other details
* COLD VIEW start: the endpoints are process start and <code>GeckoSession.load</code>. The bottleneck is unknown. A possibly important event for perceived performance is when the first frame is drawn
**The latter endpoint is available as a profiler marker
* WARM VIEW start:
 
In addition to these types of start up, there are many states/configurations a client can start up with: for example, they can have FxA set up or not set up, they may have 1000s or 0 bookmarks, etc. We haven't yet found any to have a significant impact on performance but, to be honest, we haven't yet to investigate deeply.
 
=== Page load ===
 
=== Search experience ===
 
== Performance testing ==
Performance tests can have a goal of preventing regressions, measuring absolute performance as experienced by users, or measuring performance vs. a baseline (e.g. comparing fenix to fennec). It can be difficult to write tests that manage all of these. We tend to focus on preventing regressions.
Confirm
975
edits

Navigation menu