Talos Improvement! Dromaeo (CSS) increase 3.6% on Win7 Firefox
Nobody
--------------------------------------------------------
Previous: avg 1989.541 stddev 32.991 of 30 runs up to revision b1d56e69f4d9
New : avg 2061.116 stddev 6.595 of 5 runs since revision af6bdf6ebebd
Change : +71.575 (3.6% / z=2.170)
Graph : http://mzl.la/cOrOZd
Changeset range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b1d56e69f4d9&tochange=af6bdf6ebebd
Changesets:
* http://hg.mozilla.org/mozilla-central/rev/570dc03cbf24
: Henri Sivonen <hsiv...@iki.fi> - Bug 593046 - Do not read a pref in nsJapaneseToUnicode. r=smontagu, a=blocking2.0-final.
: http://bugzilla.mozilla.org/show_bug.cgi?id=593046
* http://hg.mozilla.org/mozilla-central/rev/41aaa362225b
: Henri Sivonen <hsiv...@iki.fi> - Bug 569528 - Make <p> not close implicitly across a <button> on stack. rs=jonas, a=blocking2.0-final.
: http://bugzilla.mozilla.org/show_bug.cgi?id=569528
* http://hg.mozilla.org/mozilla-central/rev/5164c23c9e69
: Henri Sivonen <hsiv...@iki.fi> - Bug 590495 - Check for foreign elements in scope after processing a foreign end tag without forwarding to the secondary insertion mode. rs=jonas, a=blocking2.0-betaN.
: http://bugzilla.mozilla.org/show_bug.cgi?id=590495
* http://hg.mozilla.org/mozilla-central/rev/af6bdf6ebebd
: Henri Sivonen <hsiv...@iki.fi> - Bug 590498 - Change popping condition when forcibly breaking out of foreign content in HTML5 parser. rs=jonas, a=blocking2.0-betaN.
: http://bugzilla.mozilla.org/show_bug.cgi?id=590498
Bugs:
* http://bugzilla.mozilla.org/show_bug.cgi?id=569528 - [HTML5] <h5> inside <button> inside <p> implicitly closes the <p>
* http://bugzilla.mozilla.org/show_bug.cgi?id=590498 - Change popping condition when forcibly breaking out of foreign content
* http://bugzilla.mozilla.org/show_bug.cgi?id=593046 - nsJapaneseToUnicode uses the pref service off of the main thread
* http://bugzilla.mozilla.org/show_bug.cgi?id=590495 - Check for foreign elements in scope after processing a foreign end tag without forwarding to the secondary insertion mode
Nobody
---------------------------------------------------------
Previous: avg 234.777 stddev 3.050 of 30 runs up to revision b1d56e69f4d9
New : avg 246.953 stddev 1.320 of 5 runs since revision af6bdf6ebebd
Change : +12.176 (5.19% / z=3.992)
Graph : http://mzl.la/agyBD5
Nobody
-----------------------------------------------------------
Previous: avg 121.899 stddev 1.655 of 30 runs up to revision b1d56e69f4d9
New : avg 131.010 stddev 1.699 of 5 runs since revision af6bdf6ebebd
Change : +9.110 (7.47% / z=5.505)
Graph : http://mzl.la/aybtnq
Nobody
-------------------------------------------------------
Previous: avg 2018.582 stddev 20.964 of 30 runs up to revision b1d56e69f4d9
New : avg 2090.288 stddev 8.691 of 5 runs since revision af6bdf6ebebd
Change : +71.706 (3.55% / z=3.420)
Graph : http://mzl.la/dqCy1T
Nobody
-------------------------------------------------------
Previous: avg 236.673 stddev 2.463 of 30 runs up to revision b1d56e69f4d9
New : avg 247.995 stddev 1.147 of 5 runs since revision af6bdf6ebebd
Change : +11.322 (4.78% / z=4.597)
Graph : http://mzl.la/csVV7c
Nobody
---------------------------------------------------------
Previous: avg 123.748 stddev 1.616 of 30 runs up to revision b1d56e69f4d9
New : avg 133.101 stddev 1.892 of 5 runs since revision af6bdf6ebebd
Change : +9.352 (7.56% / z=5.788)
Graph : http://mzl.la/avy2ZU
Henri Sivonen
This makes no sense to me. This push seems to have unregressed the regression from my previous push. First I though I had pushed wrong patches from my MQ, but I checked the changesets and none touched nsScriptLoader.
What's going on here?
sicking, should the plan to back out the nsScriptLoader patch be canceled now that Dromaeo is magically unregressing itself?
--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/
Mike Shaver
> sicking, should the plan to back out the nsScriptLoader patch be canceled now that Dromaeo is magically unregressing itself?
Is this a PGO-related artifact? Would be good to retest those builds
a couple of times and see what we get. PGO can be deep magick, not
always friendly.
Mike
Jonas Sicking
while still not being able to figure out exactly what's going on, lets
back it out and see if we gain back the perf, and based on that figure
out where to go next.
If the recent un-regressions really did give back the loss, then
backing out shouldn't affect perf and we can land again. At that point
PGO seems like a good direction to point blame. Hopefully that can
happen quickly enough that we can still have this in for beta7. If
backing out does give us back the perf, then we need to try to
reproduce locally and try to pin-point the issue.
Backing out as soon as i'm next in queue.
/ Jonas
Henri Sivonen
> Chatted a bit here and given that this has been in for a few days
> while still not being able to figure out exactly what's going on, lets
> back it out and see if we gain back the perf, and based on that figure
> out where to go next.
The backout didn't affect Dromaeo results. After all, they had already rebounded. Furthermore, there have been other Dromaeo XP improvements that look pretty bogus. For example:
http://groups.google.com/group/mozilla.dev.tree-management/browse_thread/thread/61919a9146ccf34b#
> If the recent un-regressions really did give back the loss, then
> backing out shouldn't affect perf and we can land again.
I think the data now supports re-landing. Do you agree?