page load performance regression 2001-Nov-21-A

RESOLVED INVALID

Status

()

RESOLVED INVALID
17 years ago
17 years ago

People

(Reporter: dbaron, Assigned: darin.moz)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

After darin checked in his nsIStringStream/nsStringStream changes, the page load
numbers on tinderbox went up by 12ms.  Pulling the same changes into my own
build shows a significantly bigger change.  I pulled each of the suspicious
checkins (starting by pulling the ones between the tree closure and the
beginning of the cycle where the times went up), and got the following times:

Times are
  Avg. Median/Average/Minimum/Maximum

[pull mscott, nhotta (incl. later), chak, rpotts]

  1027/1041/558/2836
  1034/1040/562/2746

[pull brendan (both)]

  1031/1036/550/2752
  1031/1036/551/2781

[pull yokoyama]

  1033/1039/566/2792

[pull sgehani]

  1032/1039/560/2759

[pull ducarroz, cmanske]

  1035/1041/564/2775

[pull darin]

  1119/1129/561/3078
  1114/1126/564/2998


I'm going to double-check that backing out darin in my tree brings the numbers
back down, and then move on to looking at roc's regression.
OK, now I'm getting confused.  I started to back out darin's stuff in my tree,
and then I realized I never pulled his change to xpcom/build/nsXPComInit.cpp. 
So I did that, and I rebuilt and ran regxpcom, and got the numbers back down to:

  1037/1046/568/2838

So now I'm having trouble seeing the drop that showed up on tinderbox.  Maybe
partly brendan and partly darin?  Or sometheng else?

Someone probably needs to try this on another machine...
[pull xpcom/build/nsXPComInit.cpp and run regxpcom]

  1037/1046/568/2838
  1037/1042/558/2781
To quote Bart Simpson: I didn't do it!

See also bug 73382.

/be
Yeah, that's what I concluded.  This isn't measurable in a noisy environment
like a network -- only in a really controlled environment like btek.  If someone
can figure out what caused this, then it's worth reopening, but for now,
->INVALID.

FWIW, more measurements:

[back out cmanske]

  1039/1045/560/2772

[back out sgehani]

  1037/1044/559/2784

[back out brendan jslock/jsapi, run regxpcom for good measure]

  1042/1055/561/2779
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → INVALID
(Assignee)

Comment 5

17 years ago
it couldn't have had anything to do with my string stream changes since i didn't
change any executed code.
You need to log in before you can comment on or make changes to this bug.