220997 - Mozilla very slow during the load, high CPU

Status: RESOLVED WORKSFORME

(Core :: Layout: Tables, defect)

Description

[Tom Jac]

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 (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

Comment 1

[Emmanuel Bourg]

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

Comment 2

[Boris Zbarsky [:bzbarsky]]

To tables.  jprof results coming up.

Comment 3

[Adam D. Moss]

The page does takes a while to load here, and CPU usage is high, but Mozilla is
still highly interactive.  Linux/x86, 750MHz Athlon.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Attachment: 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?

Comment 5

[Nicholas Allen]

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.

Comment 6

[Markus Hübner]

The new URL seems to be:
http://www.bundesarchiv.de/findbuecher/stab/db_nachlass/include/structure.php?
cat=&UID=3775ee02de7f57570c1879f3aee226e0

Comment 7

[Boris Zbarsky [:bzbarsky]]

Old URL:
http://www.bundesarchiv.de/findbuecher/stab/nachlaesse/struktur.php?anzeigeKlassi=01.02.&ordnr=1002&syssuche=benjamin&logik=

Comment 8

[Nicholas Allen]

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

[Markus Hübner]

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

Comment 10

[Boris Zbarsky [:bzbarsky]]

And we have now passed the "one testcase per perf bug" limit.  Oops.

Comment 11

[jim_nance]

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

Comment 12

[Martijn Wargers (dead)]

The url is gone (the one in comment 7 has changed, I think).
Can we still find the original page somewhere?

Comment 13

[Markus Hübner]

URL is now:
http://www.bundesarchiv.de/zdn/
Just follow the steps as mentioned in comment #1

Comment 14

[Martijn Wargers (dead)]

WFM with current trunk build and with Mozilla1.7

Comment 15

[Markus Hübner]

Yes, let's WFM this one and open new testcases that are still slow in seperate 
bugs.