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:
Created attachment 128704 [details] table createt using DOM creates a 10.000 row table, takes some seconds to load
Created attachment 128705 [details] same table as #1, plain html attachement #1 saved as html this is about 2MB in size when unzipped!!
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 :(
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.
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