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

Status: NEW

(Firefox :: General, defect)

Description

[(no longer active)]

<http://graphs.mozilla.org/graph.html#tests=[[83,1,22]]&sel=none&displayrange=365&datatype=running>

Comment 1

[Vladan Djeric (:vladan)]

(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

Comment 2

[Kannan Vijayan [:djvj]]

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.

Comment 3

[(no longer active)]

(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.)

Comment 4

[(no longer active)]

(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...)

Comment 5

[Randell Jesup [:jesup] (needinfo me)]

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.

Comment 6

[Ed Morley [:emorley]]

This is a dupe of bug 778718 (which has just been ignored until now) surely?

Comment 7

[Vladan Djeric (:vladan)]

Oddly enough, the Telemetry metrics don't show the same clear trend:

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

Mac release: http://bit.ly/U72CqJ

Comment 8

[(no longer active)]

(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!