here is a graph showing a slight dip in dromaeo dom numbers: http://graphs.mozilla.org/graph.html#tests=%5B%5B73,132,35%5D%5D&sel=1415627790000,1415800590000&displayrange=7&datatype=running I did some backfilling and retriggering on tbpl: https://tbpl.mozilla.org/?tree=Fx-Team&startdate=2014-11-10&enddate=2014-11-12&jobname=Ubuntu%20HW%2012.04%20x64%20fx-team%20talos%20dromaeojs you can see that on this push we drop from the 940-980 range to 900-940 range: https://hg.mozilla.org/integration/fx-team/pushloghtml?changeset=9a50f667e675 Here is a reference on how to find out more about dromaeo dom tests: https://wiki.mozilla.org/Buildbot/Talos/Tests#Dromaeo_DOM

Hey jmaher, What are the chances this is just noise? I ask for a couple of reasons: 1) As I understand it, Dromaeo DOM is concerned primarily with Javascript manipulation of the DOM. The patch for bug 1090444 does not change behaviour of the DOM or Javascript - it is strictly printing related. Specifically, it is concerned with the printing progress dialog during the kickoff of a print job, which uses codepaths that should not be hit by the Dromaeo DOM tests (as far as I can tell - I cloned the Dromaeo test source at git@github.com:jeresig/dromaeo.git, and couldn't find any code to kick off printing... but I'm happy to be proven wrong!). 2) The code path I introduced should only ever be hit when running with e10s - otherwise, the component that opens the IPC communication does not get registered - the end result being that we will bypass all of this code. Can I assume Dromaeo is not running with e10s enabled? 3) And here's the kicker - on Linux, printing while in e10s mode is disabled - we show an alert box if the user tries to print. So, to sum: The code path I've introduced here should be difficult, if not impossible for the Dromaeo DOM test suite to hit. Looking at the history of Dromaeo, could this just be noise?

Mike, thanks for asking. I suspect this is really the cause as the patch previously ran and it + many other previous ones had the higher range while your patch and future patches dropped the range. it is odd this is only on linux64; while this test is noisy, I would be surprised if this was noise only or related to other environment stuff as I did a few retriggers on a set of pushes to help reduce concern there. It sounds like there is no easy fix for this if the code isn't running on linux64.

I did my own retriggers, and I concur - my patch causes a drop in dromaeo_dom performance. I'm kinda stunned. I'll see if I can gather some profiles and find out what the hell is going on.

My best guess is that the binary gets laid out somewhat differently and that affects the cache line or stack alignment of stuff....

hmm, it appears that this causes a winxp session restore regression: https://tbpl.mozilla.org/?tree=Fx-Team&startdate=2014-11-10&enddate=2014-11-12&jobname=Windows%20XP%2032-bit%20fx-team%20talos%20other_nol64 we go from ~1575 -> ~1595. A small regression, but one nevertheless.

So yesterday, I did a try push with bug 1090444 backed out on top of a recent tip, and compared it against recent tip. Here are the pushes: Backout: https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=24df604d592c With bug 1090444: https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=48d086203906 Compare-talos: http://compare-talos.mattn.ca/?oldRevs=24df604d592c&newRev=48d086203906&server=graphs.mozilla.org&submit=true Compare-talos shows no significant improvement after I backed out this patch. So... so what is going on here? bz might be right - we might have hit some kind of threshold within the compiled structure of our binary which causes us to be somewhat less efficient then before. Although, looking at an up to date graph, I also still wonder if we just saw noise: http://graphs.mozilla.org/graph.html#tests=%5B%5B73,132,35%5D%5D&sel=1414656861470.9453,1416704423114.7808,750,1075.4716981132076&displayrange=90&datatype=running With the backout not causing any kind of performance gain, I have a feeling we should close this one. What are your thoughts, jmaher?

It seems as though Dromaeo DOM is the magic test case that finds most of these issues. Maybe it is our lucky test and whenever it regresses we should play the lottery! Seriously though, there is nothing we can do for this. I would like to figure out a solution/method for determining when we move the code size enough that it causes issues in performance tests. I am going to close this as wontfix! lets move onto other great stuff.