Closed Bug 233311 Opened 21 years ago Closed 2 years ago

Very poor performance while loading MS-Excel Exported page.

Categories

(Core :: Layout: Tables, defect)

x86
All
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: dwat001, Unassigned)

References

()

Details

(Keywords: hang, perf, testcase)

Attachments

(2 files)

User-Agent:       
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040206

When browsing to the given page, http://www.tri.co.nz/confirmation.html mozilla
goes into an infianate loop, (unresponsive, 100% CPU, left running for 10 minutes)

With "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030903
Firebird/0.6.1+ " it display the screen first and then goes into the infinate loop.

This page was generated by Excel 9 (2000) and it starts like this.


<html xmlns:o="urn:schemas-microsoft-com:office:office"
xmlns:x="urn:schemas-microsoft-com:office:excel"
xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=windows-1252">
<meta name=ProgId content=Excel.Sheet>
<meta name=Generator content="Microsoft Excel 9">
<link rel=File-List href="./confirmation_files/filelist.xml">
<link rel=Edit-Time-Data href="./confirmation_files/editdata.mso">
<link rel=OLE-Object-Data href="./confirmation_files/oledata.mso">


Reproducible: Always
Steps to Reproduce:
1. Browse to http://www.tri.co.nz/confirmation.html

Actual Results:  
In Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040206
Did not draw new page, CPU went to 100% Mozilla went unresponse. (menus
scrolling close window, all other mozilla windows stop responding)

in 


Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030903
Firebird/0.6.1+

it drew the page then went in to the infinate loop.

Expected Results:  
Draw page, or not draw page, but not go unresponsive infinate loop.
The page is faily big 1832 KB
I removed the some of the repeated content (it is a list of names) to take it
down to 22KB This did not cause the problem to ocurr. 

Tryed again at 872 KB and it finished after 3:17 sec CPU time. 

So may be this is just taking a hudge amount of time to execute ( I'm on a P4
2Ghz with lots of memory so thats a lot of proccessing).

For comparison Opera renders in less the a second, IE renders in about 2 seconds.

This page seems to be to small to create the problem but gives yo9u an idea of
the HTML envoled.
the last column of the table is specified with a span of 251.  Removing that
makes the whole page load in a reasonable amount of time (25 seconds).

dupe of bug 160816?

==> tables
Assignee: parser → nobody
Component: HTML: Parser → Layout: Tables
Keywords: hang, perf
OS: Windows XP → All
QA Contact: core.layout.tables
Well, a profile of that page in the URL field shows:

Total hit count: 6800
Count %Total  Function Name
6291   92.5     nsCellMap::GetDataAt(nsTableCellMap&, int, int, int)
 80   1.2     __i686.get_pc_thunk.bx
 35   0.5     nsTableFrame::CalcBCBorders(nsIPresContext&)

and for the actual callers:


43526   0     6298 nsTableRowGroupFrame::CalculateRowHeights
              6293 nsTableFrame::RowIsSpannedInto

With pretty much all of that time spent in GetDataAt.  Marking dependent for now.
Depends on: 160816
Summary: Infinate loop while loading MS-Excel Exported page. → Very poor performance while loading MS-Excel Exported page.
Status: UNCONFIRMED → NEW
Ever confirmed: true
The patch in bug 54542 probably makes this a lot better, given that profile data
in comment 4.
the url is 404, should we close the bug or is there any reliable testcase for this?
courtesy of archive.org
Keywords: testcase
Boris, does this still have a prominent profile hot spot?
Cannot reproduce: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20100101 Firefox/12.0

Looks like this was WORKSFORME 10 years ago per comment 9, and I confirmed that the attachments load without noticeable delay for me in current Nightlies.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: