Mozilla very slow during the load, high CPU




Layout: Tables
14 years ago
12 years ago


(Reporter: Tom Jac, Unassigned)


(Blocks: 1 bug, {perf})

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




(1 attachment)



14 years ago
User-Agent:       Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5; MultiZilla v1.5.0.2Beta) Gecko/20030925
Build Identifier: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5; MultiZilla v1.5.0.2Beta) Gecko/20030925

During the load mozilla is slower and slower

Reproducible: Always

Steps to Reproduce:
1.URL ( left "Nachlässe A-z" (estates) f.i. "Nachlässe B"

Actual Results:  
Mozilla is very slow, high CPU

Comment 1

14 years ago
Confirming with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5)

The page consists in in giant table of 3Mb. The memory usage increased by 21Mb.
It took about 15 seconds to parse and display on a P4 2.6GHz
Ever confirmed: true
To tables.  jprof results coming up.
Assignee: other → table
Component: Layout → Layout: Tables
OS: Windows NT → All
QA Contact: ian → madhur
Hardware: PC → All

Comment 3

14 years ago
The page does takes a while to load here, and CPU usage is high, but Mozilla is
still highly interactive.  Linux/x86, 750MHz Athlon.
Created attachment 132526 [details]
jprof data

Basic data:

Total hits: 6791
Hits under nsTableFrame::ReflowTable: 4155

The rest are parsing, content creation, frame construction, etc.

The hits under nsTableFrame::ReflowTable are split as follows:

BasicTableLayoutStrategy::ComputeNonPctColspanWidths -- 892
nsTableFrame::GetCellInfoAt			     -- 139
nsTableFrame::ReflowChildren			     -- 1945
BasicTableLayoutStrategy::AssignPctColumnWidths      -- 1141

The rest is pretty minor.   Overall biggest time-users are:

Count %Total  Function Name
1199   17.7	BasicTableLayoutStrategy::RowSort(int*, int*, int)
539   7.9     nsCellMap::GetDataAt(nsTableCellMap&, int, int, int)
268   3.9     nsRuleNode::GetStyleData(nsStyleStructID, nsStyleContext*, int)
204   3.0     nsCellMap::GetCellInfoAt(nsTableCellMap&, int, int, int*, int*)

RowSort is called from BasicTableLayoutStrategy::ComputeNonPctColspanWidths and
BasicTableLayoutStrategy::AssignPctColumnWidths.  Is there any way to make
RowSort not take quite so much time here?


14 years ago
Keywords: perf


14 years ago
Depends on: 160816
Blocks: 234240

Comment 5

14 years ago
The test case seems out of date (it no longer produces a giant table).  Is there
an equivalent page where BasicTableLayoutStrategy::RowSort is the bottleneck? 
If the problem is RowSort getting a huge list to sort, it's easy to make RowSort

Comment 6

14 years ago
The new URL seems to be:
Old URL:

Comment 8

14 years ago
I cannot reproduce this bug.  The result sets under Nachlässe have been broken
up so there's only 100 entries displayed per page.  I did not see a way to get
the whole table at once.  I did a search which allowed me to get a nearly 1500
entry table (~2.2 MB) but there was no slow down and none of my stack samples
hit the functions in bz's profile.

Comment 9

14 years ago
There is a nice customizable table-generation testcase at
[my_trlimit and my_tdlimit can be set individually]

Maybe we can reproduce something with that
And we have now passed the "one testcase per perf bug" limit.  Oops.
Depends on: 236703

Comment 11

14 years ago
I have a similar bug to this that I am working on.  If you need a testcase of a
large table that is extreamly slow, go to bonsai and ask for a list of all the
checkins that scc has ever done.  It takes me about 30 seconds to render that
table and mozilla is effectivly dead for most of that time.




14 years ago
Depends on: 241599
The url is gone (the one in comment 7 has changed, I think).
Can we still find the original page somewhere?

Comment 13

12 years ago
URL is now:
Just follow the steps as mentioned in comment #1
WFM with current trunk build and with Mozilla1.7

Comment 15

12 years ago
Yes, let's WFM this one and open new testcases that are still slow in seperate 
Last Resolved: 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.