Closed Bug 376177 Opened 17 years ago Closed 15 years ago

Firefox very slow in rendering very large tables

Categories

(Core :: Layout: Tables, defect)

1.8 Branch
x86
All
defect
Not set
major

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: init, Unassigned)

Details

(Keywords: perf)

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3

Firefox is very slow in loading very large tables, such as forum threads with hundreds of posts. It actually loads the page fine, and I can scroll down to view newly loaded parts just as they are loaded, but for some reason, when the page seems to be finished rendering, Firefox stops responding for quite a while (tens of seconds) and CPU usage jumps to 100%.

This would have been bearable if separate tabs would use separate threads, but since all tabs seem to use only one thread, I cannot use any other tab while another is in this frozen state. I just thought that I could try the same page in Internet Explorer 7, since I run Windows for the moment, and it loaded the page much faster and there were no 20 second freeze.


Reproducible: Always

Steps to Reproduce:
1. Go to page with a very large table
2. Wait for it to load

Actual Results:  
When it is almost finished, it freezes for quite a long time

Expected Results:  
It would not freeze when finished loading
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
Your zipped page loads within a few seconds here.
While using Firefox 2.0.0.3 rv:1.8.1.3 build 20070309 under XP Pro SP2, I load your testpage (715 table rows in the file display_mess.asp.htm) in 17 sec. on my modest Pentium 3, 667 Mhz with 384 MB RAM. Note that the webpage has 5576 validation markup errors (which is a lot) and the CSS code (2.css) has 7 parsing errors and 46 warnings.

Ingemar, please try to be specific when filing bugs of this sort. If you say "slow" or "very slow", then indicate your system resources and the correspondent time duration. If you refer to large or very large table(s), then indicate the number of table rows, number of tables and, if applicable, number of nested tables. In the absolute, words like "slow" and "large" refer to nothing (comparable, reproducible) concretely speaking.

Btw, 
http://www.mozilla.org/quality/browser/front-end/testcases/copy-paste/copy-large-text/longtablepage.html
is a testcase which has 1603 table rows, 41652 validation markup errors, filesize is 244,36 KB (250 221 bytes) and might be a better testcase for testing Firefox and Seamonkey.

WORKSFORME  
(In reply to comment #3)

> Ingemar, please try to be specific when filing bugs of this sort. If you say
> "slow" or "very slow", then indicate your system resources and the
> correspondent time duration. If you refer to large or very large table(s), then
> indicate the number of table rows, number of tables and, if applicable, number
> of nested tables. In the absolute, words like "slow" and "large" refer to
> nothing (comparable, reproducible) concretely speaking.

I did write tens of seconds, and I did compare to IE7, which loaded the page almost instantaneously. And I was, and still am, in Windows, so all my text processing tools that I usually use are not available.

> http://www.mozilla.org/quality/browser/front-end/testcases/copy-paste/copy-large-text/longtablepage.html
> is a testcase which has 1603 table rows, 41652 validation markup errors,
> filesize is 244,36 KB (250 221 bytes) and might be a better testcase for
> testing Firefox and Seamonkey.

It did not freeze like my test page did. There may be some other issue with it that causes the freezing apart from the table. I'll have a look at it next time I'm running Linux (i.e. tomorrow).
Component: General → Layout: Tables
Product: Firefox → Core
QA Contact: general → layout.tables
Version: unspecified → 1.8 Branch
Could you please also test against trunk (nightlies or at least 1.9 alpha 4). The chances are slim that such a thing will get a fix on branches. BTW it renders locally < 2.0 sec on trunk for me.
Keywords: perf
Since building Firefox could take some time, I first thought that I'd try Gran Paradiso Alpha 3 in a virtual machine running Windows XP, to get a consistent environment with my previous tests. All I can say is that the test case worked perfectly, possibly slightly faster than IE7. It loaded and rendered in less than two seconds on this setup.
=> WFM per reporter comment 7
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: