556428 - [meta] Profile startup

Status: RESOLVED INCOMPLETE

(Camino Graveyard :: General, defect)

Description

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Over the past year or so, we've really eaten a bunch of startup regressions, sometimes because we didn't know what was going on, sometimes because we had to pick up things that were just slow(er).  We really need to sit down and profile startup and see what's going on and if there are things we can improve (even if those things happen not to be things that caused the regressions).

I'm including "recent" open Ts regression bugs (plus a couple of WONTFIXed ones, Growl which we think re-arranging init for 10.6 basically fixed, and a Sparkle shared regression that's probably just dyld+large symbol tables) and Dan's to-come autocomplete perf fix, since it mentions loading history at startup, so that we have a good idea of the types of places we have already regressed startup, and cc'ing folks who owned the bugs that landed the code that caused the regressions ;)

In terms of doing the actual profiling, if you want to test exactly the conditions that run on the tinderbox, you need tinderbox (or madhatter, for 1.9.2) and a tinder-config that skips the build stage or does test-only. http://wiki.caminobrowser.org/IT:Setting_up_Camino_Tinderboxen#Setting_up_Tinderbox explains setting up tinderbox and startup-test.html (if you pull madhatter into exactly the same paths as tbox, you can use exactly the same instructions and just adjust the tinder-config for 1.9.2/Hg).

There are also some additional Shark hooks available in Gecko via a custom build; see https://developer.mozilla.org/en/Profiling_JavaScript_with_Shark for more info (not sure if it will be useful at all for our needs).

Comment 1

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(Although I just realized 1.9.2+madhatter won't be useful until bug 555885 is fixed.)

Comment 2

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

JFTR, Ts for Cm2.1-M1.9.2 is about 20-25ms faster than Cm2-M1.9 and 40-45ms faster than its direct counterpart, Cm2.1-M1.9, all on cb-x4.

Cm2-M1.9:     ~525ms
Cm2.1-M1.9:   ~545ms
Cm2.1-M1.9.2: ~500ms

(In other words, on our fastest Mac, we've made back the Ts regression from switching to Places [bug 553055] and then some, but that's not to say there's not more win to be had by actually investigating the slowness introduced by Places and other checkins and fixing/optimizing said code.)

Comment 3

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Mentioning this here because there doesn't seem to have been a bug for it: after the cb-x1 rebuild (bug 513718, also tracked by Ts regression bug 458217) in September 2009, Ts slowly creeped up from about 520ms to 625ms over the course of about 3 months) on both branches.

Last night I accidentally had two instances of tinderbox running, so I had to restart :(  When cb-x1 came back on line, we'd dropped about 105ms from Ts time, to end up ~505ms on 2_0 branch and 517ms on 1.9.2.  (I'll try to remember to keep an eye on it over the next few months and see if it starts creeping up again.)

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(Also, this brings cb-x1's times back into the same range as those on cb-x4, although interestingly, 2.0.x is faster on cb-x1, but 2.1 is faster on cb-x4.)