Beginning on October 25th, 2016, Persona will no longer be an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 214175 - poor performance when loading from file vs. loading from DOM
: poor performance when loading from file vs. loading from DOM
Status: NEW
: perf, testcase
Product: Core
Classification: Components
Component: Layout: Tables (show other bugs)
: Trunk
: x86 Windows 2000
: -- normal with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
Depends on:
  Show dependency treegraph
Reported: 2003-07-28 08:28 PDT by
Modified: 2009-08-23 19:14 PDT (History)
2 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

table createt using DOM (840 bytes, text/html)
2003-07-28 08:32 PDT,
no flags Details
same table as #1, plain html (30.93 KB, application/zip)
2003-07-28 08:37 PDT,
no flags Details

Description 2003-07-28 08:28:23 PDT
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 2003-07-28 08:32:03 PDT
Created attachment 128704 [details]
table createt using DOM

creates a 10.000 row table, takes some seconds to load
Comment 2 2003-07-28 08:37:45 PDT
Created attachment 128705 [details]
same table as #1, plain html

attachement #1 saved as html
this is about 2MB in size when unzipped!!
Comment 3 2003-07-28 08:42:09 PDT
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 [:bz] (still a bit busy) 2003-07-28 12:34:29 PDT
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 2003-07-28 13:59:19 PDT
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

Note You need to log in before you can comment on or make changes to this bug.