Last Comment Bug 655860 - Major Performance Regression (tp4, Ts, TSVG)
: Major Performance Regression (tp4, Ts, TSVG)
Product: Core
Classification: Components
Component: DOM: Core & HTML (show other bugs)
: Trunk
: All All
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Andrew Overholt [:overholt]
Depends on: 655937
  Show dependency treegraph
Reported: 2011-05-09 15:40 PDT by Shawn Wilsher :sdwilsh
Modified: 2011-05-10 08:00 PDT (History)
14 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description Shawn Wilsher :sdwilsh 2011-05-09 15:40:42 PDT

Given that all of Vivien's stuff only touches mobile/, it is not a factor here.
Comment 1 Shawn Wilsher :sdwilsh 2011-05-09 15:54:50 PDT
I have this back out locally, but I'm rebuilding to make sure I don't make the tree go up in flames.

This will also back out (bug 654990) because it depends on stuff in this range.
Comment 2 Shawn Wilsher :sdwilsh 2011-05-09 16:08:01 PDT
Back out:
Merge (backs out bug 654990):

Leaving the tree closed until we confirm that this was the regression (although it likely was).
Comment 3 Matt Brubeck (:mbrubeck) 2011-05-09 19:59:29 PDT
I suspect this is related to infrastructure problems or other non-code changes.

In the OSX-tp4 graph, the last good test is on dfcfa00eb188 and the first bad test is on b2ce3817d034, even though only the "mobile" directory changed between them.

In the Win7-tp4 graph, the last good test is on dfcfa00eb188 and the first bad test is on 9e31df64bfd7, which was an *earlier* changeset whose Tp4 test happened to run *later*.
Comment 4 Matt Brubeck (:mbrubeck) 2011-05-09 20:03:14 PDT
Yup, this was due to a scheduled change to Talos:!topic/
Comment 5 Matt Brubeck (:mbrubeck) 2011-05-09 20:06:28 PDT
One changeset was missed in the backout of bug 514437; I backed it out here to fix oranges:

As we'd expect based on comment 3 and comment 4, the backout does not seem to have fixed the regression.
Comment 6 Shawn Wilsher :sdwilsh 2011-05-09 20:22:36 PDT
(In reply to comment #4)
> Yup, this was due to a scheduled change to Talos:
We should hold off on reopening the tree until we get a confirmation on that.  I'm also inclined to say that we should back out everything that landed today to get a baseline for new numbers if all that did in fact land.

With all that being said, that *only* explains the tp4 regression and not the Ts and TSVG regressions.
Comment 7 Boris Zbarsky [:bz] (still a bit busy) 2011-05-09 20:29:43 PDT
It explains the TSVG regression at least; I would fully expect bug 651659 to affect TSVG.  I really hope it doesn't affect Ts, though....
Comment 8 Shawn Wilsher :sdwilsh 2011-05-09 20:41:07 PDT
We don't need to back things out, but we do need to trigger a bunch of talos runs.
Comment 9 Shawn Wilsher :sdwilsh 2011-05-09 20:41:32 PDT
(which Matt is doing a great job of right now!)
Comment 10 Matt Brubeck (:mbrubeck) 2011-05-09 20:53:31 PDT
Looking at the first results coming in from re-triggered Talos runs on older changesets, it looks like they are showing the exact same regressions as the later changesets.  (If this holds true, it means the regression is entirely due to the Talos updates.)
Comment 11 Marco Bonardo [::mak] 2011-05-10 05:37:26 PDT
On Places branch I see similar regressions on a changeset that only fixed some cpp warnings. Checking with compare-talos on central looks like all changesets between vivien's and current tip did not cause any regression from the new baseline. The tip has double talos thanks to nightlies too.
I suspect the tree can be reopened.
Comment 12 David Bolter [:davidb] 2011-05-10 05:51:16 PDT
I reopened the tree based on Matt and Marco's assessment.
Comment 13 Shawn Wilsher :sdwilsh 2011-05-10 08:00:28 PDT
(In reply to comment #12)
> I reopened the tree based on Matt and Marco's assessment.
...which means this bug can be closed :)

Note You need to log in before you can comment on or make changes to this bug.