Closed Bug 990140 Opened 6 years ago Closed 6 years ago

3.29% regression in dromaeo dom on osx 10.6 from inbound revision 0fb101fc5976

Categories

(Core :: DOM: Core & HTML, defect)

x86
macOS
defect
Not set

Tracking

()

RESOLVED WONTFIX
Tracking Status
firefox31 - ---

People

(Reporter: jmaher, Unassigned)

References

Details

(Keywords: perf, regression, Whiteboard: [talos_regression])

peterv, does this make sense for your push?
Flags: needinfo?(peterv)
Not really, no. Also, don't think I'm seeing a regression/improvement when these patches first landed/were backed out and the only difference between that and the second landing is a change in a mochitest.
Flags: needinfo?(peterv)
Isn't this basically the same regression as bug 989414?
Flags: needinfo?(jmaher)
Boris, this regression is a slight dip for 10.6 on the 31st, and the ggc landing was on the 28th.  On the graph the larger dip is the ggc one and this is a slight shift in numbers on the 31st.

Looking back over the retriggers, we clearly dip ~20ms on revision 0fb101fc5976, although there was another ~10ms dip shortly before this (file regression bug 990233).

My theory is this did have a slight regression initially (although ggc landed around then which caused the bigger regression), and this is now triggering alerts because of the cumulative effect of the ~10ms and this ~20ms.

Avi, this is another example of a 10.6 only regression.  I know we care more about large regressions on 10.6, but your opinion here would be valued.
Flags: needinfo?(jmaher) → needinfo?(avihpit)
I've expressed my perspective in bug 985575, and Andreas Gal concurred in bug 990233 comment 10.

TL:DR; We should not care much about small 10.6-only regressions unless they're likely to indicate a bigger issue which could also affect other platforms.

3% counts as a minor regression in my book, so if it's 10.6 only and doesn't raise a flag with anyone as indicating a bigger issue, IMO let it be.
Flags: needinfo?(avihpit)
> we clearly dip ~20ms on revision 0fb101fc5976

Alright.  I suppose it's theoretically possible that the outerization changes are not being optimized as well as we would have thought by the compiler...  In theory.
Blocks: 990490
as per comment 5, and discussion in bug 990490, we should weigh looking into this with how useful our time can be spent.  As this is only 10.6, this makes it less of a priority.  If the change in question has no obvious issue or optimization to be made, I recommend resolving this as a wontfix.
Are we going to investigate this or accept this regression?
I don't think this is worth investigating.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.