214175 - poor performance when loading from file vs. loading from DOM

Status: NEW

(Core :: Layout: Tables, defect)

Description

[bugzilla.mozilla.org]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030720 Mozilla Firebird/0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030720 Mozilla Firebird/0.6

this is more a question than a bug:

I noticed that rendering of huge tables is rather slow in mozilla, compared to
other browsers. Then I tried something different: I created a uge table using
the DOM and there mozilla is way faster renering the table.

why is that? 


Reproducible: Always

Steps to Reproduce:

Comment 1

[bugzilla.mozilla.org]

Attachment: table createt using DOM

creates a 10.000 row table, takes some seconds to load

Comment 2

[bugzilla.mozilla.org]

Attachment: same table as #1, plain html

attachement #1 saved as html
this is about 2MB in size when unzipped!!

Comment 3

[bugzilla.mozilla.org]

when loading the html table it seems like the performance goes down
expotentially with the number of rows. (hope this makes sence in english)
The first 2000 rows load quite fast but then it becomes slower and the last 1000
rows take ages to load ...

And, yes. We do deal with such huge tables currently in our Intranet ...
unfortunately :(

Comment 4

[Boris Zbarsky [:bzbarsky]]

The problem is that when you create the table via DOM it's all created at once
and reflown once.

When created via the parser, we render incrementally; the goal there is to get
something up on the screen once we have it, not to completely lock up until the
whole page is loaded.  The problem is that the incremental layout is O(N^2) as a
result, because later parts of the table affect the width of earlier parts.

Note that if you actually use table-layout:fixed, the latter rows do not affect
the earlier ones.  But table-layout computes to "auto" if the table has
"width:auto".  Setting a width on the table (eg "width:100%") may help the
rendering a good bit.

Comment 5

[Markus Hübner]

Just some side-infos:
You may find tracking bug 114584 interesting.
In view of performance of large tables see bug 54542 .
Concerning slow performance on big HTML files, bz has done some investigation 
in bug 145425