214370 - Browser very slow to lay out page (nsCellMap::GetDataAt)

Status: RESOLVED WORKSFORME

(Core :: Layout: Tables, defect)

Description

[Nick M]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4; MultiZilla v1.4.0.4A) Gecko/20030624
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4; MultiZilla v1.4.0.4A) Gecko/20030624

The page begins to load, but then hangs.  I was able to duplicate this on a
Windows XP machine with a Celeron 450 MHz processor, as well as a Windows 2000
machine with an Intel 2.4 GHz processor

Reproducible: Always

Steps to Reproduce:
1.Go to http://www.pilotzone.com/palm/games_action_default.html
2.Wait
3.

Actual Results:  
Page begins to load.  Animation icon (the 'M') starts to slow down and then
freezes.  After awhile, the application icon (top left) becomes a generic
windows icon.  Have to kill the app through Task Manager.

Expected Results:  
Load the page.

Comment 1

[Nick M]

This is version 1.4 final.  I was able to also do this with Mozilla 1.3.

Comment 2

[Oleg Sidletskiy]

also happens on:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030728
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030726 Mozilla
Firebird/0.6.1

let me also add that mozilla hangs because it uses 100 % cpu.
severity: critical

Comment 3

[Mats Palmgren (inactive)]

Confirming bug, 2003-07-27-05 trunk Linux

Comment 4

[Mats Palmgren (inactive)]

The page has hundreds of table cells that have huge colspan values:
<td colspan="1110"> ...

Comment 5

[Hermann Schwab]

After seeing it with current nightly, and reading this page, I tested with
Mozilla 1.02, and Mozilla 1.02 is hanging too. OS is Win98 with SP1.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Actually, if you give it some time to think (order of minutes) it ends up laying
out the page.  So this is not a hang per se.  The performance is abysmal, though.

bernd, this looks like our good friend nsCellMap::GetDataAt:

Total hit count: 3932
Count %Total  Function Name
3475   88.4     _ZN9nsCellMap9GetDataAtER14nsTableCellMapiii
127   3.2     __i686.get_pc_thunk.bx
  9   0.2     _ZN13nsCOMPtr_baseD2Ev

Any ideas on what's going on?

If someone could produce a minimal testcase (as small a page as possible that
still shows the perf problems) that would be much appreciated.  The page is
about 500k long, and while it could be that the sheer size is causing issues,
the fact that 88% of the time is spent in GetDataAt tends to point to some other
problem (that function should not be taking such a high percentage of total time).

Comment 7

[Boris Zbarsky [:bzbarsky]]

Ah, the colspan thing may do it.... that's what the cellmap handles.

It looks like the page just increments the "colspan" attribute by 4 for every
row. Unfortunately, that means we actually treat it as a table with thousands of
columns (since that's what it claims to be) and hence the cellmap is huge....

Perhaps we should really reevaluate our storage solution for the cellmap data?

Comment 8

[Mats Palmgren (inactive)]

Attachment: Testcase (500 rows, colspan from 1000 to 1499)

This takes ~10 secs of 100% CPU on a PIII 733MHz

Comment 9

[Olivier Cahagne]

dupe of bug 160816 ?

Comment 10

[Boris Zbarsky [:bzbarsky]]

Olivier, good catch!

*** This bug has been marked as a duplicate of 160816 ***

Comment 11

[Bernd]

160816 is wfm now this one is not

Comment 12

[Bernd]

I would say this is WFM, winxp Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051221 Firefox/1.6a1