Firefox has been slower to startup by 27.93% over the past year

NEW
Unassigned

Status

()

Firefox
General
5 years ago
a year ago

People

(Reporter: Ehsan, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: c=startup_investigate u= p=)

<http://graphs.mozilla.org/graph.html#tests=[[83,1,22]]&sel=none&displayrange=365&datatype=running>
(In reply to Ehsan Akhgari [:ehsan] from comment #0)
> <http://graphs.mozilla.org/graph.html#tests=[[83,1,
> 22]]&sel=none&displayrange=365&datatype=running>

The gradual nature of the increase seems to suggest a lot of this is going to be from adding more features which require initialization at startup. I'll profile a recent build against a build from the beginning of the year to confirm this
Assignee: nobody → vdjeric
One question to ask is whether we want to explicitly encourage a policy where lazy initialization of things is preferred to startup initialization, and look to aggressively move out existing stuff happening at startup towards lazily initialized implementations.

I haven't looked at the startup code at all, but the death-of-a-thousand-cuts nature of this slowdown seems to imply a process where "one more small thing" is added to startup that cumulatively adds up over time.
(In reply to comment #1)
> (In reply to Ehsan Akhgari [:ehsan] from comment #0)
> > <http://graphs.mozilla.org/graph.html#tests=[[83,1,
> > 22]]&sel=none&displayrange=365&datatype=running>
> 
> The gradual nature of the increase seems to suggest a lot of this is going to
> be from adding more features which require initialization at startup. I'll
> profile a recent build against a build from the beginning of the year to
> confirm this

FWIW we can do a lot of magic to not initialize things at startup.  If you find things which are specifically adding to the startup time because of this, I would be more than happy to provide hints on how to fix them.  :-)  (And thanks a lot for looking into this.)
(In reply to comment #2)
> One question to ask is whether we want to explicitly encourage a policy where
> lazy initialization of things is preferred to startup initialization, and look
> to aggressively move out existing stuff happening at startup towards lazily
> initialized implementations.

In a lot of cases, that is the only tool in our toolbox (and it definitely sucks...)
I suspect a portion of it is code-size/reloc increases partly (but not totally) due to large landings like WebRTC (which landed in two chunks).  Much of this is unavoidable due to simple code size and because loading it can't be deferred (via a separate dll/.so) due to the linkage issues with XPCOM, etc.

Code size increased across the board, though, I'm sure.

How much is from webrtc, I don't know, you can --disable-webrtc to see.
This is a dupe of bug 778718 (which has just been ignored until now) surely?
Oddly enough, the Telemetry metrics don't show the same clear trend:

Windows Nightly: http://bit.ly/V7o4vZ

Mac release: http://bit.ly/U72CqJ
(In reply to comment #7)
> Oddly enough, the Telemetry metrics don't show the same clear trend:
> 
> Windows Nightly: http://bit.ly/V7o4vZ
> 
> Mac release: http://bit.ly/U72CqJ

I'm not sure how to interpret these graphs.  The stddev is 7-8 seconds!
Whiteboard: c=startup_investigate u= p=
Assignee: vladan.bugzilla → nobody
You need to log in before you can comment on or make changes to this bug.