Dave Townsend [:mossop] Assignee
	Description • 14 years ago

There is about a 50ms Ts regression on OSX 10.5.8 that needs resolving before we can land on trunk again.

	Dave Townsend [:mossop] Assignee
	Comment 1 • 14 years ago

So I've had an interesting weekend trying to narrow down just where the new add-ons manager code is causing a Ts regression on OSX 10.5.8 (not 10.6, or Linux, or Windows mind you). So far my conclusions are that it isn't the new add-ons manager code that is doing it

A Ts run consists of 20 startups of Firefox (The first is with a clean profile, the latter using the new profile it creates). The time measured is between launching Firefox and it loading a mostly empty page. The largest time is ignored and then an average is taken.

Here is a graph showing the normal times for those 20 runs (actually only 19 are listed on the graphs server for some reason) in the most recent Ts cycle on trunk: http://bit.ly/cp949Q

The first run is long but that is when we register components etc. in the new profile and do an app restart. The rest are nice and stable at somewhere just over 650ms.

Now here is a graph from just after the new add-ons manager landed: http://bit.ly/dl4zo6

Again, a long run on the first point (about the same as the previous graph in fact). Then a few runs that are of about the same time as previously. Then something strange happens. In just under half the following runs the time is nearly 100ms higher than normal. Fairly consistently too. This isn't a fluke either, the frequency and position of the longer runs changes but every Ts test with the new extension manager (on OSX 10.5.8) shows the regular low times mixed with higher times, of a pretty consistent value.

Now I may be barking up the wrong tree but I don't think it is a stretch to imagine that the regression is coming from the presence of those higher values and something different must be happening during those runs. Shouldn't be too hard to figure out right? Here is a problem graph though: http://bit.ly/bHRzCg

That graph is what I see on the add-ons manager project branch when I completely disable building of the add-ons manager. Gone is the high first point because there is no building an extensions database etc. but the bi-modal times remain. In fact I've run this test a bunch of times and with no add-ons manager the results seem to be perfectly alternate every time in this case.

A little more food for thought. Occasionally current trunk runs will see similar high Ts values: http://bit.ly/9qNBol. My best guess so far is that this has been happening for a while, rarely yet somehow some of the small changes I made outside of the extension manager are tickling a problem and making it more frequent.

	Paul [pwd]
	Comment 2 • 14 years ago

Does this mean the AOM will be re-landed?

	Dave Townsend [:mossop] Assignee
	Comment 3 • 14 years ago

(In reply to comment #2)
> Does this mean the AOM will be re-landed?

Once this bug is fixed, yes

	Paul [pwd]
	Comment 4 • 14 years ago

(In reply to comment #3)
> (In reply to comment #2)
> > Does this mean the AOM will be re-landed?
> 
> Once this bug is fixed, yes

Ah, I thought as you thought the regression wasn't caused by this, you'd re-land the AOM.

	Dave Townsend [:mossop] Assignee
	Comment 5 • 14 years ago

It looks almost certain now that this is caused by bug 519893. Catlee ran a Ts cycle while watching through VNC which gave the attached log file. For those that can't read it those are pretty stable Ts numbers, first run was 1069, following that are runs that vary between 623 and 632ms, way less variation than we had been seeing.

	Dave Townsend [:mossop] Assignee
	Comment 6 • 14 years ago

For reference this is a log from the same slave testing the same build in the same way but without VNC attached. THis time the numbers aren't stable and there are frequent 100-110ms higher values.

	Dave Townsend [:mossop] Assignee
	Comment 7 • 14 years ago

This is just bug 519893, no need to keep it separate I think.