tinderbox showing page load number increased from 1195 to 1210s check-ins possibly caused the increase are: http://bonsai.mozilla.org/cvsquery.cgi?module=MozillaTinderboxAll&date=explicit&mindate=1018405320&maxdate=1018414079 http://bonsai.mozilla.org/cvsquery.cgi?module=MozillaTinderboxAll&date=explicit&mindate=1018414080&maxdate=1018415519 assign to pavlov for now... cc'ing everyone else who checked in during those two checkin time frame, for other possible suspects. :-)
That 1195 was a fluke I think. so it really jumped from 1205 to 1210 or so. My patch shouldn't have effected Linux at all, but I'll look to see.
we now think the number is a fluke... btek reported 1215, 1217 backed out pav's change, btek reported 1199, 1198 put pav's change back into btek, now reports 1189 unexplainable reporting... so putting btek back online anc close the bug.
after putting btek back online, btek is again reporting 1216 or somewhere there... pavlov is going to try backout his changes later today on the trunk.
ok, I don't know what the deal with this is. btek seems to go up, but luna stays the same. I backed myself out earlier and re-landed afterwards to see what would happen with the tinderbox numbers. I'm unable to reproduce the slowdown on my solaris box. Since the patch for 129953 gives a *signifigant* speedup for DHTML pages on windows, I've chosen to leave the patch in right now. I will be out of the office until April 22. If you want to back it out again, thats fine with me, but please post something to bug 129953 letting them know what the status is.
luna and btek are building slightly different things. btek disables crypto, tests, and xprint. luna enables crypto, and has all extensions turned on. I suspect you're twiddling something that luna is already paying the price for, but btek is not, hence the jump on btek.
So jrgm may be able to help -- by running timers on the main thread on Windows when idle, we are probably adding a bit, noisily, to timer latency. The page load tests may care about that average increase in latency. /be
Considering the comments above, should this really be a smoketest blocker?
when pav backed out shortly last night, btek tp showed 1207, 1207, 1206, 1206 then pav re-checked in btek tp back to 1218
I have backed out pavlov's checkins. Resolving this bug as fixed
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Final numbers given seem to be 1%. For a significant improvement in DHTML functionality (not just performance) this seems worth it. DHTML functionality was broken by the previous timer checkins to reduce latency; this fixes that regression. Comments to be mirrored on 129953
Is this more important than bug 129953 which a bugfix for seems to be the reason for the little time-increase ?
reopening, I don't think we're done with this discussion yet.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Here's another datapoint: the Txul numbers on slag jumped from ~2150 to ~2650 when brade backed out pavlov's checkin. Looking at the history from last night, a similar jump occurred when pavlov backed himself out last night. slag isn't one of our officially sanctioned performance boxes but the numbers seem relatively consistent.
off blocker list, per discussion @ 3pm in my cube
Marking as nsbeta1+/ADT1
i think we should close this bug, as pavlov's change was backed out on Friday. we need one more pass on the patch for bug 129953, the fix is only for windows platform, but linux page-load was affected by the patch. please see bug 129953 for more details.
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago → 17 years ago
Resolution: --- → FIXED
removing from RC1 tracking bug.
No longer blocks: 129953
Removing adt1 since it was make so for MachV. Now tracking for Buffy
You need to log in before you can comment on or make changes to this bug.