82078 - ~30% slowdown in loading voodooextreme mock page (5/18 to 5/21)

Status: RESOLVED INCOMPLETE

(Core :: Layout, defect)

Description

[John Morrison]

I was looking at some stuff related to gordon's checkin of 
L2 Cache (single store for all metadata, instead of multiple
files). (Note: this isn't about gordon's checkin: his stuff was in
all the builds I tested).

I  was curious about a slight slowdown between Friday night and Monday morning. 
The reason (modulo some noise) is that we lost about a full second in loading 
this page:

http://jrgm/perf/loadtime5/base/www.voodooextreme.com/index.html

Here are the times I recorded, two test runs with each build.
The first visit is uncached, and the second is cached (although
Linux may have evicted some of the content in 3,4,5, leading to 
a "mixed cached" visit).

Win98
                       #1      #2      #3      #4      #5      
  2001051822 Run #1   3500    3257    3398    3480    3537    
  2001051822 Run #2   3537    3262    3370    3431    3589

  2001052111 Run #1   4550    4381    4495    4574    4723
  2001052111 Run #2   4608    4412    4552    4550    4688


Linux
                       #1      #2      #3      #4      #5      
  2001051821 Run #1   4236    4134    4135    4102    4130
  2001051821 Run #2   4229    4176    4165    4152    4100

  2001052112 Run #1   5724    5461    5434    5438    5428
  2001052112 Run #2   5590    5410    5410    5423    5458


So, you can see that this slowed by about a full second after
checkins of about 9pm Friday, and checkins of ~8am Monday.

That voodooextreme page has a history with Layout (cf. bug 20485)

In general, it's a big, pull-out-all-the-tricks kind of page, although
one particularly unusual thing that it does is to perform many small 
'document.write()'s into the document.

I noticed that vidur had actually checked in some stuff related to 
script processing, but it's before the checkin window that I've noted.

I'm not sure what "acceptable" is for that page, but I thought I should
note this and not just drop it on the floor. Any one wanted to review
the checkins?

Comment 1

[anthonyd]

Hey John,

I load this page now, and it seems really fast.  ow do I re-test this (with 
actual time being quantified)?

Thanks,
Anthony Davis

Comment 2

[John Morrison]

Hmm, well, not sure what to do with this bug now (6 months later).

Current times for this page on the same hardware are ~3200/2800 uncached/cached
on win32, and 4600/4500 uncached/cached on linux. So, times are down from 
May, although still higher on Linux than they were before 5/18. 

(As a side observation, I wonder why Linux is >1.5 slower than win32 for this
page, when (overall for these 40 pages) it's about 1.3 slower.)

Comment 3

[anthonyd]

who do i reassign this bug to then? someone in the performance group, or just 
close it?

Comment 4

[John Morrison]

voodooextreme is an unusual page that has had a history of blowing up mozilla 
in the past, and even now (e.g., this page shot up to 45 seconds a month ago).
That's why I opted to include this page as part of the test (it does some fugly
stuff).

I don't know if it's worth figuring out what caused this particular regression
in time for this page, now that 6 months have past. Maybe, maybe not, maybe 
there are bigger bang for the buck problems to tackle.

waterson/karnaze: what say you?

Comment 5

[anthonyd]

reassigning to watterson as a possible performance benchmark.

Comment 6

[José Jeria]

URL is dead.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months.
:dholbert, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 8

[Daniel Holbert [:dholbert]]

--> incomplete per comment 6.