graph server shows a CART regression: http://graphs.mozilla.org/graph.html#tests=[[309,63,21]]&sel=1401992531000,1402165331000&displayrange=7&datatype=running this is the offending push: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=4511d9ac1000&tochange=79624417d247 I did some retriggers, no question that this push is causing problems: https://tbpl.mozilla.org/?tree=Mozilla-Inbound&fromchange=d0a624d910d1&tochange=dea1f56f3feb&jobname=Rev4%20MacOSX%20Snow%20Leopard%2010.6%20mozilla-inbound%20talos%20svgr according to datazilla: https://datazilla.mozilla.org/?start=1401477498&stop=1402082298&product=Firefox&repository=Mozilla-Inbound&os=mac&os_version=OS%20X%2010.6.8&test=cart&graph_search=79624417d247&x86=false&project=talos we have these subtests regressed: 3-customize-enter-css.error.TART 1-customize-enter.error.TART and these regressed, but not as extreme: 1-customize-enter.all.TART 2-customize-exit.all.TART 2-customize-exit.error.TART 3-customize-enter-css.all.TART 3-customize-enter-css.half.TART for more information about the tests, here is some documentation: https://wiki.mozilla.org/Buildbot/Talos/Tests#TART.2FCART

I don't have a 10.6 machine easily available, so I'm gonna try a few things on try and hope that that's enough to figure things out. My current theory is that we're slowing down because we're not caching CG surfaces when we used to before.

(In reply to Michael Wu [:mwu] from comment #1) > I don't have a 10.6 machine easily available, so I'm gonna try a few things > on try and hope that that's enough to figure things out. > > My current theory is that we're slowing down because we're not caching CG > surfaces when we used to before. If it helps, I can allow you to remote into my 10.6 talos clone that I have on my desk. Let me know if you want to set that up.

(In reply to Michael Wu [:mwu] from comment #1) > I don't have a 10.6 machine easily available, so I'm gonna try a few things > on try and hope that that's enough to figure things out. > > My current theory is that we're slowing down because we're not caching CG > surfaces when we used to before. FYI, we're not generally interested in improving OS X 10.6-only regressions. See bug 990490. So unless you think this change has implications on other platforms (mobile/b2g included), we probably shouldn't put much effort into it. Joel, is the "offending" bug 1011211 ?

the offending bug is 994081 From what I have seen this is only affecting 10.6. I would be happy to turn this test off for 10.6 if we are going to scrap a 10% regression for the sole reason that it is on 10.6.

Let me try some things first - I have a relatively simple fix in mind which should improve things on all OSX versions.

(In reply to Joel Maher (:jmaher) from comment #4) > the offending bug is 994081 Thanks. Generally you do put the causing bug at the title, right? > From what I have seen this is only affecting 10.6. I would be happy to turn > this test off for 10.6 if we are going to scrap a 10% regression for the > sole reason that it is on 10.6. I don't think we should remove the test only because it regressed, even we it ends up as wontfix. It could still help detect "important" regressions as bug 990490 suggests.

for the record, this doesn't show as a regression on aurora: http://graphs.mozilla.org/graph.html#tests=[[309,63,21],[309,52,21]]&sel=1397236375171,1405012375171&displayrange=90&datatype=running the reason is we had a larger win and this regressed part of the win- so for the aurora uplift we ended up with an overall win.

this is way too old to do any real work on.