This slipped through the list of regressions on trunk, but when we uplifted to Aurora, I was able to see this. here is a link to the graph server: http://graphs.mozilla.org/graph.html#tests=[[83,52,21]]&sel=none&displayrange=30&datatype=running I did a bunch of retriggers on inbound and found a couple offenders, but one was backed out. The winning patch is: https://hg.mozilla.org/integration/mozilla-inbound/rev/45ac7b7d7466 You can see on inbound how it bumps the ts_paint values for osx T(o) from ~1060 -> ~1090: https://tbpl.mozilla.org/?tree=Mozilla-Inbound&fromchange=46e56e65ecc7&tochange=62c2807d9680&jobname=mozilla-inbound%20talos%20other

this seems to be the cause for the win7 ts paint regression as well, we see it go from ~880 to ~890

any updates on this? We are a couple weeks into this regressions time on Aurora.

(In reply to Joel Maher (:jmaher) from comment #2) > any updates on this? We are a couple weeks into this regressions time on > Aurora. I tried to repro this on OS X a few days ago but hit some weird Python errors with the mach command :( I can try again tomorrow maybe but I'll need some way to repro this locally first.

I verified from inbound (pulled early april 1, 2014) that I could run 'mach talos-test other' and run tests. alternatively, you can follow these wiki instructions to do it outside of mach: https://wiki.mozilla.org/Buildbot/Talos/Running#Running_locally_-_Source_Code

(In reply to Joel Maher (:jmaher) from comment #4) > I verified from inbound (pulled early april 1, 2014) that I could run 'mach > talos-test other' and run tests. That works for me now too. When I open "$build/mozharness/build/talos.txt" there are 20 values for ts_paint, unfortunately there's a lot of noise so a 2% regression is hard to measure. Is the number on tbpl the mean or median of these, or something else? It's possible that we compile a bit more code with bug 939562; I can check if that's the case. Maybe we can workaround it somehow but I'm not sure.

what you see on tbpl is a single number which is to remove the max value from the list and return the median of the remaining 19 values.

checking in on this bug, we are getting closer to the uplift date.

The problem is probably that with bug 939562 we Baseline-compile more scripts on startup. We really need bug 939562 for a number of reasons though, one is to get fast JS for chrome code and addons. We could use different use count thresholds for chrome code, but then we're introducing another chrome/content distinction and making our heuristics more complicated again. I'm not sure if doing that is worth it...

Jan, thanks for adding more context to this. The Win7 regression is minimal, the OSX one is larger- but 10.6 is a much smaller portion of our user base. Avi, what are you thoughts on this?

vladan is probably better than me at assessing the importance of startup regressions. That being said, according to this: (In reply to Jan de Mooij [:jandem] from comment #8) > We could use different use count thresholds for chrome code, but then we're > introducing another chrome/content distinction and making our heuristics > more complicated again. I'm not sure if doing that is worth it... It sounds to me Jan thinks the cost of fixing it would be to high. If I were to decide, I'd say wontfix. Vladan?

The regression is small (at most 2-3% on any platform), it's worst on 10.6 which soon won't have many users, and Jan says this patch will give us chrome & addon JS performance improvements. Let's mark this WONTFIX.