152385 - very large pages cause disproportionately long load time

Status: RESOLVED DUPLICATE of bug 148636

(Core :: Layout: Tables, defect, P4)

Description

[Peter Zillmann]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530
BuildID:    2002053012

I can't show you this page, unfortunately, because it contains sensitive data.
I'll give you my best description.
The page is just under a megabyte in size: all text. It's a table with 4000
rows, 1400 textareas and 1400 option boxes. On loading it takes about a minute
to process, takes up all my memory (512MB) and causes general system instability
afterwards.
The obvious solution is not to go to pages this large. That's not an option. I
have the same problem with the commercial release of Netscape. Internet Exploder
and Opera process the page in about ten seconds.
Hope that helps. I love Mozilla.

Reproducible: Always
Steps to Reproduce:
1. Go to page.
2. Watch.

Actual Results:  Page loaded after about a minute of cranking.

Expected Results:  Loaded page more quickly.

Sorry I can't give you a public page to try this in. Make a table with a
gajillion rows where the whole damned thing is a form and you'll see it.

Comment 1

[Oliver Klee]

Over to HTML Tables.

Comment 2

[Daniel Wang]

nope, not a table problem.

I tried two test html files, one with 60 or so forms, each containing one
checkbox and one textarea, and one with a table with the same number of rows.
The first test renders much slower than the second. So I suspect it's a problem
of creating control objects effectively.

a solution could be setting the max string length for the textarea.

Comment 3

[Michael Lefevre]

reporter (or someone else): can you reproduce this problem with a recent build
of mozilla? if so, could someone attach a test file which shows the
disproportionate slowness? if not, please resolve this bug as WORKSFORME. thanks.

Comment 4

[Peter Zillmann]

I can confirm this bug is still with us. Just tested it again with Mozilla 1.1b
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721

Had the same experience. A competitor's browser loaded the page in 15 seconds. I
stopped waiting for mozilla to render the page after 8 minutes.

Comment 5

[Peter Zillmann]

I taught myself perl and whipped up a mock-up of the page without all the
sensitive information that the original contains. I've made two versions of the
page: one with 20 three-row records and one with 2000. If you want to see what
it looks like, I'd recommend the 20 record version, as it loads in Mozilla with
no problem. You can see for yourself what the problem looks like itself with the
2000 record version.

http://www.zillmann.org/cgi-bin/bug152385-20.pl
http://www.zillmann.org/cgi-bin/bug152385-2000.pl

And once again, you all rock for looking at this. Mozilla rules.

And I'm sorry if I'm doing this wrong.

Comment 6

[Rainer Bielefeld]

Reply to #5
I can confirm the Problem with
http://www.zillmann.org/cgi-bin/bug152385-2000.pl
and Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.1b) Gecko/20020818
Load-speed is very slow (only more or less 5% of my possible ISDN-speed)
System-stability gets bad

I watched that for 20 seconds and then I stopped because I was afraid that my
system might crash

IE6 loads rather quick (app. 15 seconds), but also has problems with te page:
Some Input-Panes (containing "first thing") do not scroll correctly with the
rest of the page, if I use the scroll-knob on the scrollbar. 
The IE6- Problem might have been caused by having loaded the page with mozilla
before, I will test again after a restart.

Comment 7

[Peter Zillmann]

Reply to #6
I'm glad the examples are helpful.
I have witnessed the same scrolling problem you reported with IE6 (option boxes
not displaying correctly during scrolling) only on a Windows Me box up to this
point. I've seen Opera 6.04 do the same thing. I've never witnessed it in
Windows 2000 with any browser. I don't know how the operating system might play
in to this, but I felt it worth mentioning.
And thanks again for helping to address this issue.

Comment 8

[Rainer Bielefeld]

I decided to set this bug "new".
May be the problems are also caused by mistakes in the html-code, but there
should not be caused hangriscs or similar problems by corrupted code.

I am not shure whether the problem are "tables", so component should be set back
to "Browser general"

Comment 9

[Juha Luoma]

I've setup a different test case. This loads fine with Opera 6.05 and IE 5.5 but
with Mozilla 1.1 build 20020824 loading this page takes at least 10 times longer
and eats up CPU time much more than the other browsers. I'm running W2k.
Testcase is here: <http://kotisivu.mtv3.fi/jjjj--l/big_table.html>.

Comment 10

[Juha Luoma]

I made some measurements with W2000 task manager. I loaded the big_table.html
from comment #9 locally to the hard disk. Then I started the web browser,
recorded used CPU Time, opened the file from local disk and waited for the
browser to completely load the page and then recorded the used CPU Time again.
Here are the results:

W2000 SP2, IBM ThinkPad 600X (450 MHz PIII, 256 MB)

              Start      End       Used 
                                   seconds

Mozilla       0:00:34    0:01:59   85           6 times more than IE 5.5!
2002090604

Opera 6.05    0:00:03    0:00:18   15

IE 5.5        0:00:01    0:00:15   14

Comment 11

[Markus Hübner]

Once bug 54542 is fixed this will also be considerably faster.

Comment 12

[Andrew Schultz]

this is probably a dupe of bug 148636.  each form control (at least textboxes)
get 43 EventListeners (among other things).  Any perf hit here is probably
overshadowed by swapping due to memory usage.

A table this small (2000 or even 4000 rows) should not be a perf or memory
problem.  See bug 148338

Comment 13

[Markus Hübner]

Probably also related to bug 94587.

Comment 14

[karnaze (gone)]

mass reassign to default owner

Comment 15

[XFox]

http://us2.php.net/get/php_manual_en.html.gz/from/a/mirror is another one of
those pages. It's over 1 mb. It does survive the long load times though. But if
you try viewing the source, everything goes unresponsive.

Comment 16

[Peter Zillmann]

(In reply to comment #12)
> this is probably a dupe of bug 148636.  each form control (at least textboxes)
> get 43 EventListeners (among other things).  Any perf hit here is probably
> overshadowed by swapping due to memory usage.
> 

If I had found bug 148636 before I created this one, I wouldn't have submitted
this bug. I don't know if it's really the same issue, but it sure sounds like it
to me. If a reporter's opinion is worth anything, I move that this bug be
resolved as a dupe.

Comment 17

[Peter Zillmann]

I'm convinced it's a dupe, so I'm possibly stepping out of line by trying to
officially classify it as a dupe.

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