1098295 - 5.72% Linxu32 Dromaeo DOM regression on inbound (v.36) Nov 12 from push c9b063da7562

Status: RESOLVED WONTFIX

(Core :: XBL, defect)

Description

[Joel Maher ( :jmaher ) (UTC -8) (PTO back normal Nov 17)]

Graph server shows us a dromaeo dom regression:
http://graphs.mozilla.org/graph.html#tests=%5B%5B73,131,33%5D%5D&sel=1415745879000,1415918679000&displayrange=7&datatype=running

I did some retriggers on tbpl:
https://tbpl.mozilla.org/?tree=Mozilla-Inbound&fromchange=90731dbaab2d&tochange=f53ad1a63b58&jobname=Ubuntu%20HW%2012.04%20mozilla-inbound%20talos%20dromaeojs

You cansee that when we go from a range of 870-890 down to 820-840 when this set of patches landed:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=8dbb9eef253b&tochange=c9b063da7562

looking carefully at the graph, you will see that some of the loss is fixed, we are now in the 860-875 range, so the larger picture doesn't show as much of a regression.

Comment 1

[Boris Zbarsky [:bzbarsky]]

I don't see why those patches would have affected dromaeo-DOM at all except via GC noise.  There's no XBL involved anywhere close to dromaeo-DOM, and I'm pretty darned sure I didn't change the scope chain for normal toplevel scripts.

Comment 2

[Joel Maher ( :jmaher ) (UTC -8) (PTO back normal Nov 17)]

This is the second bug related to dromaeo dom today (different linux platform though) where it doesn't look obvious the patch is the culprit.  Could this be some library ordering thing?  The retriggers via tbpl do show a drop, I am not sure if there is anything we can realistically do about it though.

Comment 3

[Joel Maher ( :jmaher ) (UTC -8) (PTO back normal Nov 17)]

this doesn't hit our 10% mark as we uploaded to beta, shall we close this?