-22ms regression to cold view nav start (7/15)

[mcomella]

From Nightly 7/14 we see 1.925s to Nightly 7/15 1.947s:

[Mugurell]

@mcomella Just curious, can you share a link to the query for this graphs?

[mcomella]

@Mugurell Focus and fenix. You should be able to sign in with OAuth.

[Mugurell]

Looking at the evolution of the startup data between 7/13-7/24 and the commits merged in that period (focus, A-C) there isn't anything that would stand out to explain the 38ms increase followed immediately by a 42ms drop (other than some changes in GV).

 

And if we look at data for a longer period it seems like this differences are common to "cold view nav start" with the performance being generally the same.

@mcomella Would you agree just closing this based on the small differences which which are leveling up in time?

[mcomella]

Performance triage: we want to discuss this when csadilek is around. Notes on what we discussed:

• we'll run into these kinds of questions and unactionability on any performance regression that it is small enough that the date of regression is ambiguous; bimodals make this especially hard. Generally, how should we handle issues like these?
• the fenix team mentions there are higher priorities they'd rather focus on, like larger regressions https://github.com/mozilla-mobile/focus-android/issues/7576 – should we mark non-P1 or close it because it's unrealistic we're going to get to this, especially with how unactionable it feels?
  • We've seen a major performance improvement – ~120ms – is this unactionable change worth the effort/gain ratio?
  • [mcomella] perhaps there's something about how strict the team wants to be around start up regressions. Being strict requires great tools though.

[MarcLeclair]

Triage: It would be better to talk about it as a whole group / separate session.

[MarcLeclair]

Closing: 22ms is too hard for us to be actionable at the moment with our current tooling since the start up time can vary by that much.