<Regression> Mozilla-Inbound - Tp5 Optimized (Main RSS) - MacOSX 10.7 - 15.6%

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

Regression: Mozilla-Inbound - Tp5 Optimized (Main RSS) - MacOSX 10.7 - 15.6% increase
-------------------------------------------------------------------------------------
Previous: avg 222824083.333 stddev 1893933.111 of 12 runs up to revision 38f9db86956e
New : avg 257631083.333 stddev 11203540.507 of 12 runs since revision 9dac032e1ffc
Change : +34807000.000 (15.6% / z=18.378)
Graph : http://mzl.la/15vfTl5

Changeset range: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=38f9db86956e&tochange=9dac032e1ffc

Changesets:
* http://hg.mozilla.org/integration/mozilla-inbound/rev/ba51eb5cccf2
: Daniel Holbert <dhol...@cs.stanford.edu> - Bug 885424 part 0: Shift declarion of 'frameCrossSize' down to where it's actually used. r=dbaron
: http://bugzilla.mozilla.org/show_bug.cgi?id=885424

* http://hg.mozilla.org/integration/mozilla-inbound/rev/d34ed2e650aa
: Daniel Holbert <dhol...@cs.stanford.edu> - Bug 885424 part 1: Set aStatus at the very beginning of flexbox reflow, and call NS_FRAME_SET_TRUNCATION at the very end. r=dbaron
: http://bugzilla.mozilla.org/show_bug.cgi?id=885424

* http://hg.mozilla.org/integration/mozilla-inbound/rev/9da12a105835
: Daniel Holbert <dhol...@cs.stanford.edu> - Bug 885424 part 2: Perform flexbox main-axis alignment separately from cross-size determination, to more closely match the ordering of steps in flexbox spec. r=dbaron
: http://bugzilla.mozilla.org/show_bug.cgi?id=885424

* http://hg.mozilla.org/integration/mozilla-inbound/rev/9dac032e1ffc
: Daniel Holbert <dhol...@cs.stanford.edu> - Bug 885424 part 3: Rename flexContainerMainSize to contentBoxMainSize, for clarity, and mark that & 'frameMainSize' as const. r=dbaron
: http://bugzilla.mozilla.org/show_bug.cgi?id=885424

Bugs:
* http://bugzilla.mozilla.org/show_bug.cgi?id=885424 - Refactor flexbox layout logic to make pagination more straightforward

[Daniel Holbert]

dev-tree-management-bot is incorrectly blaming my push for this regression.

My push only touched new-flexbox layout code, which should be unused in
our TP tests (unless they've been rewritten to use new CSS recently).

Plus, if you actually look at the graph, there's a
clearly-within-the-noise 0.1% "regression" on my push 9dac032e1ffc,
followed by a much more significant 13.5% regression on mattwoodrow's
subsequent push (b61b7f2e0d0b), whose csets are here:

http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?changeset=b61b7f2e0d0b

No idea why tbplbot blamed my push.

In any case, the regression went away after a few more pushes, likely as
a result of by this cset:
http://hg.mozilla.org/integration/mozilla-inbound/rev/f8257d93273a
which was a backout of b61b7f2e0d0b, one of the commits in mwoodrow's
push (for bug 888562). (It was backed out due to leaks.)

That fixing cset doesn't get credited in the graph, because it
apparently didn't get test results; so, the graph's first back-to-normal
point is credited to the next push, a metro-only commit (d65cb3cb55f5),
which clearly has nothing to do with this mac regression. :)

So all is well, I think. I'll post on bug 888562 to indicate that we
should watch for Tp regressions if & when that re-lands.

~Daniel

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

[Matt Brubeck]

On 7/9/2013 10:46 PM, Daniel Holbert wrote:
> No idea why tbplbot blamed my push.

In case anyone else is curious, this was another "spooky action at a
distance": https://bugzilla.mozilla.org/show_bug.cgi?id=879903

Specifically, the backout that was exactly 12 pushes after Daniel's
affected the regression analyzer's "average of the 12 following pushes"
for Daniel's push. I have a plan fix this but I haven't had time to
work on it; see the bug for details (especially if you'd like to help).