Confirming, setting to NEW Tested on Win7 x64 latest hourly m-c build: https://hg.mozilla.org/mozilla-central/rev/206305cbbeb1
Assignee: nobody → general
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: general → general
No problems with the site in IE9, or the latest Chrome Dev version.
From about:jank (plus an xperf run, and the fact that the site has a huge HTML file) it looks like this is mostly layout (though possibly DOM; xperf shows 3% of time in mozjs.dll and 80% in xul.dll).
Assignee: general → nobody
QA Contact: general → layout
I tried Gecko Profiler addon from Github (not on clean profile) and got after loading and fully loading (loop is still indicating loading but site loading to be functional for me).. and here is what I got: Link: http://varium.fantasytalesonline.com/cleopatra/?report=AMIfv97e7YT6nebB8Gkv5By1MQOnDwRSpHC0vQ0Izy0W1lnOOtPp0JnmM0xSQCaPQkxJMqZPXhjGr_gkM7BKs7JEgn2-j-u3luQPjJlT9zHqrdtNb4NG06LSxCRM3lofrCQEdh2k8mnU4XfZ60J_zQrQrMr22s4scQ Total Samples: 3872 Selection: --Range: [0,3872] --Avg. Responsiveness: 1021.88 ms --Max Responsiveness: 10717.14 ms 3872 (100.00%) Startup::XRE_Main 2376 (61.36%) ??? Unknown 1229 (31.74%) Input::nsInputStreamPump::OnInputStreamReady 195 (5.04%) Timer::Fire 68 (1.76%) event::nsViewManager::DispatchEvent 2 (0.05%) html5::RunFlushLoop 1 (0.03%) layout::FlushPendingNotifications 1 (0.03%) nsEventListenerManager::HandleEventInternal Maybe of some worth... so posted..
OK, so... The "infinite loading" bit is expected: the page does a document.write() after the parser is done, so it opens a new document and never closes it. For the rest... the page does a half-dozen XHRs to get a bunch of XML. It parses each one to see whether it needs to get more, then throws the result of the parse away. Once it has all the XML it goes through, parses all the XML strings _again_, gets data out of the resulting DOMs, sorts it, then document.write()s a bunch of strings out to show some HTML for this, one tiny bit at a time. I did a quick profile, and the majority of the time seems to be under document.write. in particular, 65% of the time is spent in nsHtml5OwningUTF16Buffer::AddRef/Release! Another 25% is spent in various other parser stuff, Henri, the refcounting bit looks like the search through those linked lists in Parse() to find the right place in the queue.... why are we hitting the slow case in this situation? In any case, I'm pretty sure we have a bug on this part.
Component: Layout → HTML: Parser
QA Contact: layout → parser
(In reply to Boris Zbarsky (:bz) from comment #5) > Henri, the refcounting bit looks like the search through those linked lists > in Parse() to find the right place in the queue... The search used to avoid refcounting, but refcounting was added just in case in response to review comments. See 696651 bug comment 17 and other comments in that bug. > why are we hitting the slow case in this situation? I haven't debugged this yet, but a reasonable expectation is that the page manages to block the parser and then does many document.writes in little pieces, so it all needs to be buffered up.
> The search used to avoid refcounting, but refcounting was added just in case in response > to review comments. Right; the real problem I see is not the refcounting but the asymptotic characteristics of the algorithm used. I'm not sure what would block the parser in this case, but can we do anything to make whatever search is going on here faster in common cases (e.g. searching from the end if that would help)?
OK, more details. Every single Parse() call is coming in with a null aKey. So we're doing a linear search down to mLastBuffer on each one. This is silly, imo.
OS: Windows 7 → All
Hardware: x86_64 → All
Summary: UI hang + Infinite loading + JS Script warning on site → UI hang + Infinite loading + JS Script warning on chromium nightly builds listing
Version: 12 Branch → Trunk
Created attachment 614102 [details] [diff] [review] When we have a null aKey, don't do a linear search down to mLastBuffer.
Comment on attachment 614102 [details] [diff] [review] When we have a null aKey, don't do a linear search down to mLastBuffer. Henri, is this at all sensible? Other options include having a prev pointer on these buffer objects or having an mNextToLastBuffer on the parser itself, if you don't think that changing what mLastBuffer points to is acceptable. This patch _does_ make the page load in fairly finite time.
Attachment #614102 - Flags: feedback?(hsivonen)
Comment on attachment 614102 [details] [diff] [review] When we have a null aKey, don't do a linear search down to mLastBuffer. Makes sense. Good observation that firstLevelMarker and the sentinel are same-looking objects.
Attachment #614102 - Flags: feedback?(hsivonen) → feedback+
Comment on attachment 614102 [details] [diff] [review] When we have a null aKey, don't do a linear search down to mLastBuffer. OK, in that case I think we should just get this in.
Attachment #614102 - Flags: review?
Assignee: nobody → bzbarsky
Target Milestone: --- → mozilla14
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
This is still not fixed for me, while I don't see the not-responding and pages ghosting out during load, the throbber in the tab still continues to 'run' even though page appears to be fully loaded. Win7 X64 latest m-c hourly build which contains the patch: https://hg.mozilla.org/mozilla-central/rev/e1bef8037d36
Jim, please read comment 5.
Sorry, that was a bit abrupt... The throbber thing is a matter of the page not being done loading from the browser's point of view. There are other bugs that cover that. We generally aim for one bug per issue, and the key issue here was the browser hanging.
You need to log in before you can comment on or make changes to this bug.