562427 - Investigate if lazy DOM subtree deletion would make any sense

Status: NEW

(Core :: DOM: Core & HTML, enhancement, P5)

Description

[Olli Pettay [:smaug][[e-mail]]]

Attachment: proof-of-concept

Subtree deletion could be done lazily, so that while looping in JS
and doing for example .innerHTML += "<b>foo bar</b>";
not so much time (like 10%) was spent in deleting DOM elements.

Of course this doesn't really make things faster, but just splits some operations
to happen later.

Feel free to say this is an idiotic idea :)

Comment 1

[Boris Zbarsky [:bzbarsky]]

If we could do the delete off-thread, it'd be worth it.  Otherwise it just seems like cheating, no?

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

It is a bit like cheating yes, but it does allow processing user input faster.

Comment 3

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Except that it causes a bigger pause once we do delete the nodes.

Do you have an example of a page that suffers from unresponsive input and that would be helped by this patch?

Comment 4

[Johnny Stenback (:jst)]

What's the expensive part of DOM node deletion? If it's the call to delete, then we could let a different thread do that, but there's certainly parts of DOM node destruction that we can't do off the main thread (mNodeInfo release etc).

Comment 5

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

All optimization is cheating; if we defer the reclaiming until an idle point in the event loop, and delete a few nodes per cycle, we'll clean up the memory pretty quickly without much pausing.  (If we're deleting a bazillion nodes in a single go, we have to address that regardless of whether we do it eagerly or lazily, IMO.)

I forget why we need to do reference count management on mNodeInfo at all, but I'm sure it's a good reason. :-)

Comment 6

[Boris Zbarsky [:bzbarsky]]

Well, the other option would be to give nodeinfos document lifetime, right?

Reclaiming at idle and deleting incrementally (with a fallback if we have too many nodes waiting to die) makes sense to me.

Comment 7

[Daniel LaLiberte]

One thing to consider is that the disconnected DOM nodes should behave exactly as if they were fully deleted, except for occupying space and taking a bit more time to clean up during idle times.  In particular, any ids referencing these nodes need to be unbound (or whatever the term is here) from the nodes, and similarly, form fields need to be removed from the form scope.  

I would imagine this disconnection phase, which needs to be done synchronously (is it??), ought to be faster than full garbage collection of the nodes, which could be done asynchronously.

By the way, I am looking for ways to ensure these kinds of things after changes such as setting innerHTML to clear or change the content.  When are ids bound or unbound?  Is there any way to force this besides repeatedly checking after timeouts?  Thanks.

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #7)
> I would imagine this disconnection phase,
"Disconnection phase" happens earlier than what this bug is about.
Well, except perhaps for document object. 

> By the way, I am looking for ways to ensure these kinds of things after changes
> such as setting innerHTML to clear or change the content.  When are ids bound
> or unbound?  Is there any way to force this besides repeatedly checking after
> timeouts?
When an element is added to a document (e.g. document is its ancestor), and it
has ID, it is added to the ID map. Similarly when an element is removed from
a document (e.g. document is not anymore its ancestor), it is removed from
the ID map. That all happens synchronously; you may want to look at
nsStyledElement::BindToTree and nsStyledElement::UnbindFromTree.
But ID handling has nothing to do with this bug.

Comment 9

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.