75868 - Consequences of some checkin on April 9th (mostly goodness, but Mac wants some too)

Status: RESOLVED DUPLICATE of bug 75988

(SeaMonkey :: General, defect)

Description

[John Morrison]

As I had noted in news://news.mozilla.org/3AD3FDCE.8FAC7B6D%40netscape.com
something really unusual changed with the builds for Tues 04/10 (i.e., 
a checkin from Monday). While at the same time that we began loading 
7 pages that we were not previously loading, the times for many of the 
33 pages that we were loading on Apr 6th-9th dropped big-time (at least
according to the firing of 'onload').

Now, among the 7 pages that began to load again were some of the 
slower pages (e.g., tomshardware, voodooextreme, etc.). Adding these 
back in the the calculation of average time drives that average time higher.
So, when you look at the overall numbers, windows stayed flat, linux 
dropped ~5% and Mac went up ~10%. 

But in the charts I'll attach, I just plot the results for each platform for 
only the 33 pages that were loading in builds of Apr 6,9,10,11,12. From them
you can see that (1) win98/linux times for many of these pages dropped by a 
good margin in builds of Apr 10, and stayed consistently so for Apr 11 and 12.
(2) the Mac "went nuts".

(These charts show median times for "already cached" visits. The "first visit"
times show some even more dramatic decreases on win32/linux).

Anyone want to look further to figure out (a) what win98/linux goodness was 
behind this, and (b) why Mac didn't respond in the same way. 

-> pinkerton, just because he asked :-]

Comment 1

[John Morrison]

Attachment: win98 before/after Apr9th; "already cached" load times for 33 urls

Comment 2

[John Morrison]

Attachment: linux before/after Apr9th; "already cached" load times for 33 urls

Comment 3

[John Morrison]

Attachment: win98 before/after Apr9th; "already cached" load times for 33 urls

Comment 4

[John Morrison]

Attachment: Mac before/after Apr9th; "already cached" load times for 33 urls

Comment 5

[John Morrison]

Ignore http://bugzilla.mozilla.org/showattachment.cgi?attach_id=30731, the 
third attachment above (or rather it's labelled in this bug report as win98,
but it's actually the Mac graph, same as the fourth attachment). (copy/paste
error).

Comment 6

[Simon Fraser [no longer active]]

I think this is the batch of checkins we need to eyeball:
<http://bonsai.mozilla.org/toplevel.cgi?treeid=SeaMonkey&batchid=508>

Comment 7

[Simon Fraser [no longer active]]

Checkins that I think should be looked at more closely
1. aaronl's focus appearance stuff. Maybe mac stylesheets have bad focus rules?
2. attinasi's nsBlockFrame change
3. darin's necko API changes
4. waterson's Terminate() change in nsParser

Darin's checkins are by far the most extensive here, so my guess is that this is 
him.

Comment 8

[Darin Fisher]

i know it's tempting to suspect me in this case, but all i did was move around
some functions and rename some interfaces.  i don't see how this could be me.

Comment 9

[Blake Ross]

Aaron was just adding some prefs to change the appearance of focus, so I don't 
see how that would really be it either.  Next up, marc.

Comment 10

[Marc Attinasi]

Aaron's changes do a bit of work, potentially. For example, they register a new
pref-changed callback, so there will be potentially more calls at startup as
those prefs are read (and he fixed an old pref-change callback that I mistyped).
Also, we now install another set of generated style rules. Anyway, I agree that
it is unlikely that those are contributing to any speedup or slowdown, or any
platform-based performance differences.

As for my changes, they are only relevant if some script is used to change a
list item's position from 'outside' to 'inside', which I doubt is happening. The
onLoad handler would have to be changing the style of list items to
'list-style-position: inside'. Even if it was, my changes result in slightly
more work being done, but it is inconsequential performance-wise.

Any other guesses? I'm curious why those 4 checkins are being focused on too.

Comment 11

[Simon Fraser [no longer active]]

attinasi: i'm focussing on those checkins, because they look like the only 
checkins for that day which could contribute to the problem.

Comment 12

[Marc Attinasi]

sfraser, I pretty much assumed that that was the reasoning, I was unclear about
why the other 26 checkins are NOT suspect though. More to my point, I'm curious
about hyatt's ChromeRegistry changes too.

Comment 13

[John Morrison]

this is just the mirror twin of bug 75988

*** This bug has been marked as a duplicate of 75988 ***