613487 - Terrible performance on page with lots of checkboxes

Status: RESOLVED DUPLICATE of bug 536910

(Firefox :: Session Restore, defect)

Description

[Boris Zbarsky [:bzbarsky]]

STEPS TO REPRODUCE:

1)  Load https://build.mozilla.org/clobberer/
2)  Try to check some stuff
3)  Take too long to do it

ACTUAL RESULTS: browser suddenly freezes up for a few tens of seconds

EXPECTED RESULTS: Don't do that

DETAILS:  A profile shows lots of calls through proxies; in particular they all seem to land in the slow xpconnect paths, not quickstubs.  :(  I see QI on DOM nodes being called from script, GetLocalName, previousSibling/nextSibling, etc, etc.  Only about 1/6 of the time under CAllMethod is landing under NS_InvokeByIndex_P, though; the rest is NativeData2JS, security checks, etc.

Total time is split 50-50 between getPropertyDescriptor on XrayWrapper and js::ExternalGetOrSet.

The general code being executed ran off a timer, so I bet it's session restore...

Comment 1

[Boris Zbarsky [:bzbarsky]]

In particular, this is making it take _forever_ for me to clobber some builds.

Comment 2

[Boris Zbarsky [:bzbarsky]]

I filed bug 613498 on the xpconnect issues; leaving this for the actual JS code.

Comment 3

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

This sounds a lot like bug 536910. We tackled a couple things there (in the blocking bugs) to reduce accessing the DOM already. If there's more to be done I'm more than happy to make this happen.

Looking at the form, everything is id-less, so I think this is actually dupe-able.

FWIW, most of the dom access you're hitting (GetLocalName, previousSibling/nextSibling, etc) are being called from XPathHelper.generate - http://hg.mozilla.org/mozilla-central/file/tip/browser/components/sessionstore/src/nsSessionStore.js#l3826

Comment 4

[Boris Zbarsky [:bzbarsky]]

Um... That function is quadratic in number of elements it deals with, no?  Or worse?  I guess all that's covered in bug 536910?

I wonder whether we can just expose a few C++ apis here to make this stuff _way_ faster...  Or whether the sessionstore code could cache a bit more info to make itself faster.

Comment 5

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

Bug 478107 was filed back when bug 477564 was being worked on to make sessionstore not have to actually deserialize.

It looks like you also mentioned taking attachment 361801 [details] [diff] [review] to help with the algorithmic slowness.

I thought I remember there being talk of having a native xpath generator, but I can't find that. Perhaps it was just bug 478107

Comment 6

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

Just going to mark dupe. Doesn't seem like we're covering any new ground here.