Closed Bug 136677 Opened 22 years ago Closed 22 years ago

page-load (tp) increased by 1.5%


(Core :: XPCOM, defect)

Not set





(Reporter: cathleennscp, Assigned: pavlov)


(Keywords: perf, regression)

tinderbox showing page load number increased from 1195 to 1210s

check-ins possibly caused the increase are:

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.
Blocks: 129953
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.

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
Closed: 22 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.
Resolution: FIXED → ---
Keywords: smoketest
Keywords: smoketest
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
Keywords: smoketest
Marking as nsbeta1+/ADT1
Keywords: nsbeta1+
Whiteboard: [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.

Closed: 22 years ago22 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
Whiteboard: [adt1]
Component: XP Miscellany → XPCOM
You need to log in before you can comment on or make changes to this bug.