<Regression> Firefox-Non-PGO - Dromaeo (DOM) - XP - 2.1%

[nob...@cruncher.build.mozilla.org]

Regression: Firefox-Non-PGO - Dromaeo (DOM) - XP - 2.1% decrease
----------------------------------------------------------------
Previous: avg 193.857 stddev 1.412 of 30 runs up to revision ea373e534245
New : avg 189.784 stddev 0.402 of 5 runs since revision 84320dffec6e
Change : -4.073 (2.1% / z=2.884)
Graph : http://mzl.la/VyfANq

Changeset range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ea373e534245&tochange=84320dffec6e

Changesets:
* http://hg.mozilla.org/mozilla-central/rev/84320dffec6e
: Daniel Holbert <dhol...@cs.stanford.edu> - Bug 822804: Mark variables destIdx & destPos in GfxDriverInfo.h as unsigned, to fix build warning for unsigned/signed comparison. r=Bas
: http://bugzilla.mozilla.org/show_bug.cgi?id=822804

Bugs:
* http://bugzilla.mozilla.org/show_bug.cgi?id=822804 - GfxDriverInfo.h:156: warning: comparison between signed and unsigned integer expressions

[Daniel Holbert]

Looks like we may have a (tiny) real regression here, but the
purportedly blamed commit isn't responsible. The blamed commit,
84320dffec6e, was a trivial fix: just changing two variables from signed
to unsigned, to match how they're used.

The previous commit (ea373e534245) was a 174-cset merge from inbound to
central -- that seems much more likely to have brought in something
that's responsible for the regression.

~Daniel

> _______________________________________________
> dev-tree-management mailing list
> dev-tree-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tree-management
>

[Daniel Holbert]

On 12/26/2012 09:01 AM, Daniel Holbert wrote:
> Looks like we may have a (tiny) real regression here, but the
> purportedly blamed commit isn't responsible. The blamed commit,
> 84320dffec6e, was a trivial fix: just changing two variables from signed
> to unsigned, to match how they're used.
>
> The previous commit (ea373e534245) was a 174-cset merge from inbound to
> central -- that seems much more likely to have brought in something
> that's responsible for the regression.

Also: There was a similar email for a regression on Mac OS 10.7 on
central, and that one blamed ea373e534245:

https://groups.google.com/d/msg/mozilla.dev.tree-management/uhKohE3iuJY/U4-rMG-i_cEJ

...and there were reports of 2-3% Dromeo regressions on mozilla-inbound
on 12/21 and 12/22, for 3 different platforms:
https://groups.google.com/d/msg/mozilla.dev.tree-management/fwuqdzPxOp0/3RbFiZQwfDAJ
https://groups.google.com/d/msg/mozilla.dev.tree-management/RxpZZ0WszlU/iHcPWyTZeq0J
https://groups.google.com/d/msg/mozilla.dev.tree-management/k3fdTRSzw7w/ZCHm0M4RTWAJ


Those m-i regressions' blamed cset-ranges were all included in the merge
ea373e534245, which I suspect of causing this m-c regression.

So it looks like there's something in that merge that indeed regressed
Dromaeo by 2-3% -- likely something in one of those blamed inbound-ranges.

>From glancing at the blamed csets, it looks like there are some DOM
bindings changes from peterv and Ms2ger, which look most
likely-to-be-guilty at first glance (given that Dromaeo is a DOM test).
CC'ing them.

[Daniel Holbert]

On 12/26/2012 09:20 AM, Daniel Holbert wrote:
> ...and there were reports of 2-3% Dromeo regressions on mozilla-inbound
> on 12/21 and 12/22, for 3 different platforms:
> https://groups.google.com/d/msg/mozilla.dev.tree-management/fwuqdzPxOp0/3RbFiZQwfDAJ

Oh, I just noticed that that ^^ thread included a post from bz saying
that this is almost certainly from bug 815149. I've now commented on
that bug, asking whether a backout is appropriate:
https://bugzilla.mozilla.org/show_bug.cgi?id=815149#c13