Closed Bug 432950 Opened 17 years ago Closed 17 years ago

Ts regression following bug 54488

Categories

(Core :: Widget: Cocoa, defect)

PowerPC
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: alqahira, Assigned: jaas)

References

Details

(Keywords: perf, regression)

What I don't understand is why there's a *Ts* regression here at all.... From what I could tell on the Fx boxes, neither Tp nor Tdhtml were affected (and only boxset was running those two tests for Camino, and it was still crashing). The regression is *very* clear on cb-xserve01 and probably would be on boxset if it had been working. It's less clear on Firefox perf boxen; many of them show no appreciable change, and a couple others showed a regression that cleared up at first and then maybe re-appeared (or came from other checkins). CmTrunk cb-xserve01: ca. 810ms -> ca. 1064ms (31% regression) FxTrunk qm-pmac-01: ca. 1430ms -> ca. 1520ms (6.2% regression) qm-pmac-trunk04,05,06 all showed significant but mostly temporary spikes at this checkin. The net result was that their Ts "swing-range" seems to have nearly doubled afterwards, with low values remaining about the same while high values are about double pre-checkin ones. http://graphs.mozilla.org/graph.html#spst=range&spstart=1210161600&spend=1210307837&bpst=Cursor&bpstart=1210161600&bpend=1210307837&m1tid=103000&m1bl=0&m1avg=0&m2tid=211197&m2bl=0&m2avg=0&m3tid=211302&m3bl=0&m3avg=0&m4tid=211373&m4bl=0&m4avg=0 (I can't figure out how to make that give you just the data points in question, but the checkin was 15:22 07 May.) The other Fx Mac perf machines didn't show a noticeable Ts change from the checkin. The fix is clearly a huge UE win so I'm obviously not going to advocate backing it out, but it would be useful to understand why Ts was affected (and if there's anything we can do to mitigate).
(In reply to comment #0) > The fix is clearly a huge UE win so I'm obviously not going to advocate backing > it out, but it would be useful to understand why Ts was affected (and if > there's anything we can do to mitigate). Regardless of the UE win, per regressions of this magnitude should at least get considered for blocking.
Blocks: 54488
Flags: blocking1.9?
What exactly is benchmarked by Ts? Where can I find an overview of these benchmarks and what they do? Where can I monitor "boxset"?
(In reply to comment #2) > What exactly is benchmarked by Ts? I believe it measures the time to launch the app to about:blank and reports the best score of 10 runs. See http://mxr.mozilla.org/mozilla/source/tools/performance/startup/startup-test.html and http://mxr.mozilla.org/mozilla/source/testing/tinderbox-standalone-tests/Tests/StartupPerformanceTest.pm > Where can I monitor "boxset"? Via build-graphs.mozilla.org, though since it had been crashing running Tp for the last week, there's not really any useful data. Now that I have it running again, Ts seems 1-2ms higher in general than last week, so it's not showing a measurable regression there. Tdhtml is about 1% slower than last week, but given we didn't have boxset producing data during the checkin, it's unfair to blame bug 54488 for that. It looks like the only salient regressions here are on cb-xserve01 and qm-pmac-01 (aka qm-pmac-fast01 on the waterfall)
We've got 7 machines running Ts for Mac (3 at 10.4, 3 at 10.5, and 1 running the minimal set of tests). For example the 10.4 builds: http://graphs.mozilla.org/#spst=range&spstart=1210118400&spend=1210344076&bpst=Cursor&bpstart=1210118400&bpend=1210344076&m1tid=103000&m1bl=0&m1avg=0&m2tid=103065&m2bl=0&m2avg=0&m3tid=103115&m3bl=0&m3avg=0&m4tid=102923&m4bl=0&m4avg=0 Do show a serious Ts regression.
Thank you, Mike and Smokey. Bug 54488 makes two changes that might affect performance: (1) For every widget it draws, it asks the top level window if it's activated. (2) Whenever a childView recieves a focus event, it redraws the window. I'll try to write a patch that optimizes (2) to only redraw when it's really necessary. If that doesn't help, I'll look into (1).
Marking blocking for investigation
Flags: blocking1.9? → blocking1.9+
Note also that if you look at the average/median values for pre-checkin and post-checkin instead of lowest-to-highest (which is what the checkin itself produced; the previous build was at the low point of the pre-checkin range, and the first post-checkin build went to the high point of the new range), which I would have reported if I hadn't been so tired last night, the Ts regression in Firefox was only half as bad (3-4% instead of 6-7%).
Was this fixed by the bug 54488 backout?
looks like it to me, Ts went down to previous numbers
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.