Last Comment Bug 818257 - Firefox has been slower to startup by 27.93% over the past year
: Firefox has been slower to startup by 27.93% over the past year
Status: NEW
c=startup_investigate u= p=
:
Product: Firefox
Classification: Client Software
Component: General (show other bugs)
: unspecified
: x86 Mac OS X
: -- normal with 7 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-12-04 13:43 PST by :Ehsan Akhgari (busy, don't ask for review please)
Modified: 2016-05-04 19:49 PDT (History)
17 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description :Ehsan Akhgari (busy, don't ask for review please) 2012-12-04 13:43:04 PST
<http://graphs.mozilla.org/graph.html#tests=[[83,1,22]]&sel=none&displayrange=365&datatype=running>
Comment 1 Vladan Djeric (:vladan) 2012-12-04 13:57:05 PST
(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] 2012-12-04 14:04:47 PST
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 :Ehsan Akhgari (busy, don't ask for review please) 2012-12-04 14:43:46 PST
(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 :Ehsan Akhgari (busy, don't ask for review please) 2012-12-04 14:44:52 PST
(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] 2012-12-18 11:49:24 PST
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] 2012-12-20 17:08:40 PST
This is a dupe of bug 778718 (which has just been ignored until now) surely?
Comment 7 Vladan Djeric (:vladan) 2012-12-24 13:55:56 PST
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 :Ehsan Akhgari (busy, don't ask for review please) 2013-01-03 16:50:40 PST
(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!

Note You need to log in before you can comment on or make changes to this bug.