835547 - BrowserElementChild.js startup taking ~60 samples (~120ms) on critical startup path

Status: RESOLVED WORKSFORME

(Core :: DOM: Core & HTML, defect)

Description

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

For example, this profile of Template app startup

http://people.mozilla.com/~bgirard/cleopatra/#report=2d71953e8c89fa872949df729c730fe0429b789d

The majority of that time is going to BrowserElementChild._init().  A nontrivial amount of time is also going to cp_init(), which is surprising.

Comment 1

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Can we .jsm'ize some of this code for win?

Comment 2

[Justin Lebar (not reading bugmail)]

I believe we established some months ago that most of this time in _init went into the first call which touched docShell.  I don't know if preloading about:blank changes this equation.

Comment 3

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

That doesn't appear to the case in the profile in comment 0, but I admit it's very hard to tell.  (The profile was made with the about:blank preload patch applied.)

Comment 4

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

I think Vivien is working on this incidentally in bug 835809.

Vivien, cp_init() in BrowserElementChild.js is taking a surprising number of samples, ~15 (== ~30ms).  Do you have wins for that?

Comment 5

[[:fabrice] Fabrice Desré]

I may also have improved that in bug 835548, moving from registering N message listeners to a single one.

Comment 6

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Not specific enough to be useful anymore.  We've squeezed wins out of this code.