a dromaeo css regression on windows 8 has been found, this is better than finding a leprechaun: http://graphs.mozilla.org/graph.html#tests=[[72,131,31]]&sel=none&displayrange=7&datatype=running here are some retriggers: https://tbpl.mozilla.org/?tree=Mozilla-Inbound&fromchange=e2db1c06a933&tochange=d459cc1b5a94&jobname=WINNT%206.2%20mozilla-inbound%20talos%20dromaeojs We have a list of changes that are the lucky winners: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=a1c7ec654ec4&tochange=32f9d85a4ad8 the list is long because we had a build failure on windows. As patch authors, I would like to get your opinion on if your patch could affect dromaeo css.

Given that dromaeo css mostly measures JS speed and the patch in bug 976536 is the only one that touches SpiderMonkey, it superficially looks suspicious. However, that patch selectively disables an optimization that decreases memory usage, but potentially increases CPU utilization. So if anything, it should affect the benchmark positively. Then again, there was an improvement in dromaeo css the day after the optimization landed (which was January 10, in bug 886193), so that might have partly been reverted. I remember seeing an unexpected improvement in some benchmark, which might well have been this one. I was never sure if there was actually a causal link or just correlation by chance. In either case: if bug 976536 is to blame, there isn't much we can do about it, really.

on datazilla this looks to be yui.html: https://datazilla.mozilla.org/?start=1396379452&stop=1396984252&product=Firefox&repository=Mozilla-Inbound-Non-PGO&os=win&os_version=6.2.9200&test=dromaeo_css&x86=false&error_bars=false&project=talos

thanks Till, this is a small regression and a single platform (although a more popular platform). Avi, can we get your blessing here as a wontfix?

I'm not intimately familiar with the causes for the regression, but comment 1 is convincing enough to me. I'd join the wontfix.

Bug 987680 was backed out, and the numbers didn't go back to where they were, hence it can't be to blame, removing dependency.

can we get to a decision here on wontfix vs hunting this down?

(In reply to Joel Maher (:jmaher) from comment #6) > can we get to a decision here on wontfix vs hunting this down? What would impact be on our users if we did not block on this?

impact on users- it appears that on windows 8 only we have slower javascript parsing in the dromaeo benchmark. While this is minimal, it is a more common and growing platform. I doubt any end user will see a difference unless a website is written and heavily uses whatever features are being slowed down here.

Untracking. Beta 6 should be released today and we won't block the release on this bug.

this has been released with no intent to fix- lets get rid of this bug :)