hang on page with a LOT of tables

RESOLVED WORKSFORME

Status

()

--
critical
RESOLVED WORKSFORME
11 years ago
6 years ago

People

(Reporter: dzbarsky, Unassigned)

Tracking

(Depends on: 1 bug, {hang, testcase})

Trunk
x86
Windows XP
hang, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007071305 Minefield/3.0a7pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007071305 Minefield/3.0a7pre

When you open the page, browser hangs at 50% cpu and around 550Mb RAM

Reproducible: Always

Steps to Reproduce:
1.Open testcase

Actual Results:  
It hangs

Expected Results:  
It should render the tables
(Reporter)

Comment 1

11 years ago
Created attachment 272271 [details]
Zipped version of testcase
(Reporter)

Updated

11 years ago
Keywords: hang
Version: unspecified → Trunk
Status: UNCONFIRMED → NEW
Component: General → Layout: Tables
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → layout.tables
Attachment #272271 - Attachment mime type: application/octet-stream → application/zip
Comment on attachment 272271 [details]
Zipped version of testcase

er, this is rar, not zip.
Attachment #272271 - Attachment mime type: application/zip → application/x-rar
As far as I can tell all the time is being taken up by parsing and content model construction.  In particular, of the 849204 total hits, 803875 are under ResumeParse.

About 12% of that is tokenization, the rest is under BuildModel().

My profile never saw StartLayout called before I killed the app.  So all that time really is content construction.

250351 hits are under nsHTMLInputElement::DoneCreatingElement.  Interestingly, this is not bug 352390.  The time is largely spent under KeyAppendInt.  Most likely because of the very deep nesting (there are no </table>s on that page, and 90000-some <table>s) and lack of a <form> tag, so we end up doing the fixptr-like thing.

I really wonder whether we could just eliminate running this code completely...
Depends on: 352390
Created attachment 272602 [details]
Zipped-up profile

Filed some bugs blocking this one on obvious wins.  This is a profile with those patches already applied.

Looks like mostly parsing and content construction.  Now 16% tokenization, various parser overhead (CNavDTD::CanPropagate, CNavDTD::CreateContextStackFor, CNavDTD::CanContain) adding up to another 16%.  Lots of textnode creation.  Good bit of nsINode::AppendChildTo (with BindToTree taking up a good bit of time; checks for editability sort of jump out at me).  Good bit of actual element creation.

Nothing unusual for a large testcase really.  I even saw this start to render a bit.  ;)
Attachment #272602 - Attachment is patch: false
Attachment #272602 - Attachment mime type: text/plain → application/zip
Depends on: 388422

Comment 6

11 years ago
Do you know why nsScannerIterator::operator++() is showing up in the profile?  I'd expect it to be inlined away.
Scanner strings are fragmented across packet boundaries, operator++() needs to jump across buffers, which makes it expensive, and it's not declared as being inline.

Comment 8

11 years ago
(In reply to comment #7)
> it's not declared as being inline.

403       self_type& operator++()
404         {
405           ++mPosition;
406           normalize_forward();
407           return *this;
408         }

How is this not inline?
Oh, sorry. I bet the problem is normalize_forward, then. I was misremembering.

Updated

10 years ago
Keywords: testcase
(Reporter)

Comment 10

6 years ago
Nowadays, the page consumes 50% CPU for a bit and then 100% CPU for a few seconds, but the browser is responsive the whole time and I can switch tabs.  It took about 16 seconds to render the page.  No hang, so WFM.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.