User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5; MultiZilla v22.214.171.124Beta) Gecko/20030925 Build Identifier: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5; MultiZilla v126.96.36.199Beta) Gecko/20030925 During the load mozilla is slower and slower Reproducible: Always Steps to Reproduce: 1.URL (http://www.bundesarchiv.de/findbuecher/stab/nachlaesse/struktur.php) 2.click left "Nachlässe A-z" (estates) 3.click f.i. "Nachlässe B" Actual Results: Mozilla is very slow, high CPU
Confirming with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030916. 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
To tables. jprof results coming up.
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
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 faster.
The new URL seems to be: http://www.bundesarchiv.de/findbuecher/stab/db_nachlass/include/structure.php? cat=&UID=3775ee02de7f57570c1879f3aee226e0
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.
There is a nice customizable table-generation testcase at http://www.heise.de/ix/browser/tables/index.php? what=text&my_trlimit=5000&my_tdlimit=30 [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.
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. Thanks, Jim
The url is gone (the one in comment 7 has changed, I think). Can we still find the original page somewhere?
URL is now: http://www.bundesarchiv.de/zdn/ Just follow the steps as mentioned in comment #1
WFM with current trunk build and with Mozilla1.7
Yes, let's WFM this one and open new testcases that are still slow in seperate bugs.