Closed Bug 457607 Opened 16 years ago Closed 16 years ago

mozilla-central performance regression midday 2008-09-28

Categories

(Core :: General, defect)

defect
Not set
blocker

Tracking

()

RESOLVED FIXED

People

(Reporter: dbaron, Unassigned)

References

Details

(Note that there was a separate regression and backout about 12 hours earlier, for the landing and backout of bug 448830 at 00:38 / 03:14.)
For Windows, last known good is: http://hg.mozilla.org/mozilla-central/rev/60221b1e9513 first known bad is: http://hg.mozilla.org/mozilla-central/rev/c6797cdbac48 For Mac regression above, last known good is: http://hg.mozilla.org/mozilla-central/rev/8211431bf8a6 and first known bad is: http://hg.mozilla.org/mozilla-central/rev/60fc5f224a5b Unfortunately those are not overlapping ranges. (And based on what happened when sdwilsh backed out, I'm not sure I believe the changeset that talos prints anyway.)
Hrm... I guess I can see bug 396519 causing a performance regression _maybe_ (though the RSS issue that correlated with that initially is fixed, so I don't see how it would). I can also see bug 433616 maybe causing a problem if I messed up one of the document viewer changes, though I just double-checked the obvious culprits and there should have been no changes on the codepaths Tp and Ts test... Conveniently, neither the relevant tests runs on tryserver. I guess we should try backing things out or something... I can try to do that tomorrow (Monday). :(
Though if someone has a chance to do so before then, go for it. I certainly have no idea how those patches would regress performance, much less only on some but not all platforms.
FWIW, pushlog has a hidden feature so you can look at regression ranges given a known good and known bad changeset: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=60221b1e9513&tochange=c6797cdbac48 http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8211431bf8a6&tochange=60fc5f224a5b Also, I'm pretty sure Talos gets the changeset ID from the application.ini, so it's correct. Of course, since it's not testing clobber builds, YMMV.
I just backed out bug 433616. Let's see what happens.
(In reply to comment #3) > Conveniently, neither the relevant tests runs on tryserver. I guess we should > try backing things out or something... I can try to do that tomorrow (Monday). > :( I wouldn't trust tryserver numbers anyway. I've had to back two things out now that caused bad perf regressions that didn't even show up on the try server (on tests it runs)
(In reply to comment #6) > I just backed out bug 433616. Let's see what happens. This helped Txul on Windows but not Tp on OS X.
Blocks: 433616
So I went through all the other intersections of {Tp3, Txul} * {Linux, Mac OS X 10.4, Mac OS X 10.5, Windows XP, Windows Vista} and the only other one I could find that regressed is Tp3 on Windows XP: http://graphs.mozilla.org/graph.html#show=395008,395020,395048,912148,1431867&sel=1222345273,1222712738 That said, some of the systems are too noisy on some of the tests to tell.
I backed out bug 396519 and relanded the first changeset of bug 433616 in an attempt to fix Tp and narrow down Txul.
And I'd note that it looks like the backout that already happened fixed both Txul and Tp3 on Windows XP, but didn't change Mac OS X Tp3 numbers.
Backing out bug 396519 did fix Tp on Mac.
Marking fixed.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
So we relanded part 1 of bug 433616, then part 2, then backed out part 2. Neither of them seemed to have an effect, although there was a separate regression around the time we relanded part 2 that caused the re-backout. I also notice the Tdhtml numbers on Windows XP were affected: http://graphs.mozilla.org/graph.html#show=395032,395040,395060,912141,1431915
You need to log in before you can comment on or make changes to this bug.