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

Comment on attachment 272271 [details] Zipped version of testcase er, this is rar, not zip.

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

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. ;)

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.

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

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.