23218 - [perf] slow load time for www.warzone.com

Status: VERIFIED DUPLICATE of bug 20485

(Core :: Layout, defect, P3)

Description

[John Morrison]

Opening and assigning this to myself until I break this down (I think
there are several aspects to this performance issue (and it is a bona fide
pig for the porkjockeys to consider)).

From comments in n.p.m.builds:

 | > Does anyone know why there is a visible slowness in M12??  I've compiled
 | > it myself.  Is it because of all the debugging code that's in there,
 | > perhaps...along with the gdb option, wouldn't this add overhead??  Is
 | > there any way I could see what the "real" speed of it would be so that I
 | > could gauge it for myself??  Thanks.
 |
 | I can't answer this question, but I can confirm the symptoms.  I'm running
 | the latest available from CVS and it is _slow_.  One of the browser-buster
 | pages, www.warzone.com, takes over 300 seconds to appear.  By comparison,
 | Netscape 4.7 takes less than 12 seconds, including the DNS lookup.  That's
 | over 25 times slower.
 |
 | Now my machine is not exactly a speed demon (it's a Macintosh 8500/150
 | running MkLinux) but it's not that slow, either.  One of Linux's strengths
 | is to be able to utilize less-than-current hardware effectively; there are
 | several organizations that repackage old machines for surfing the net.  If
 | the browser is too slow, this isn't feasible...
 |
 | I've also noticed that destroying a webshell during shutdown is really
 | slow, too.  If I run the browser buster overnight and accumulate 1800 or
 | 1900 webshells and then hit quit, initially it takes two or three seconds
 | to destroy each webshell.  It gets faster as it goes along; when it gets
 | below a hundred or so, they are being destroyed at the rate of two or three
 | a second, which is still not really fast enough.

... and ...

 | I'm running an optimized build of M12 on my Solaris 7 box.
 |
 | www.warzone.com (dns lookup & total loading time)
 |
 | Mozilla 4.7, (built optimized for solaris 2.5.1) = 43 seconds loading
 | Mozilla 5 M12, (built optimized for solaris 2.7) = 298 seconds loading
 |
 | I used the following flags when doing a ./configure:
 |
 | --enable-optimize --disable-tests --disable-debug
 |
 | So there are some visible differences in loading time.  I'm running a USR
 | Courier 56K analog, to put things into perspective.

Previous bugs mentioning warzone -- bug #1564 and bug #1686 (but that's
'correlation by query' -- I haven't reviewed these bug reports as to whether
it's relevant to this bug report).

Note that the same C class domain for warzone.com hosts (and is likely
authored by the same folks):
   www.voodooextreme.com -- ([perf] bug #20485)
   www.gamefan-network.com

Comment 1

[John Morrison]

Attachment: testcase; with 'empty' <SCRIPT> blocks (the slow case)

Comment 2

[John Morrison]

Attachment: testcase; 'empty' <SCRIPT> blocks removed (the fast case)

Comment 3

[John Morrison]

This bug is primarily the same as bug #20485, which is for
www.voodooextreme.com -- it is authored by the same folks, using the same
pattern of a single, deeply-nested table (5 deep) with <script>-generated
content deep in the tables.

However, while looking at the HTML, I stumbled across this observation: the
presence of <SCRIPT> inside the tables, even when the <SCRIPT> _does_not_
_generate_any_content_ can severely slow down layout. I've attached two
testcases that are exaggerated examples to make the difference clear.

                                       Nav       Moz
                                     ------------------
       With 'empty' <SCRIPT> blocks:   2.6s     20.1s
    Without 'empty' <SCRIPT> blocks:   1.9s      0.8s

  Notes: Running on win95, 133MHz/24MB thinkpad -- Nav is Nav 4.6,
  Moz is 2000010416 -- Results of 4 tests after making sure that
  each browser is "steady-state" for loading this page -- Times
  measured using the BODY .onload() event.

I realize that you are working on these issues and that it is not generally
possible to know beforehand whether <SCRIPT> will append content. It may well
be that the cost of optimizing for this 'special case' would outweigh any
real-world performance gains. But, I thought I would pass this along for
consideration. Cheers, John.

Comment 4

[troy]

Yes, the issue of script tags slowing things down is a known issue, and Vidur
will be fixing it soon

Marking as a DUP of 20485

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

Comment 5

[John Morrison]

Which is the known issue:

   1) That <SCRIPT>document.write('foo');</SCRIPT> forces a notification.
   2) That <SCRIPT>  //no code           </SCRIPT> forces a notification.
   3) *both* 1 and 2 are known issues

If it's #3, then this is a DUPLICATE. Otherwise, it's not.

Comment 6

[troy]

It's #3. Right now anytime we see a SCRIPT tag we flush in the content sink.
That's the problem Vidur will be fixing

In addition to the script problem, we have a problem with incremental reflow of
table cells being very slow.

Comment 7

[John Morrison]

Thanks for the update. Marking VERIFIED.