[webkit-dev] scoping Node destruction during DOM modifications

[Ryosuke Niwa]

On Thu, Mar 1, 2012 at 4:50 PM, Ojan Vafai <ojan at chromium.org> wrote:

> We have a lot of code (e.g. in ContainerNode.cpp or any of the editing
> code) that needs to RefPtr nodes to make sure they're not destroyed due to
> synchronous events like blur, mutation events, etc. For example,
> ContainerNode::removeChild needs to RefPtr the parent to make it's not
> destroyed during a sync event.


This sounds like a nice feature.

I uploaded two performance tests to that bug:
> 1. Set innerHTML = "" on a node that has half a million children. This
> test goes from ~166ms to ~172ms on my machine. A 3.6% regression.
> 2. Destroy half a million nodes *during* a synchronous event (uses
> range.deleteContents). Goes from ~284ms to ~342ms. A 20% regression.
>

I'm surprised that we get a 20% regression. Can we try inlining all
functions in DOMRemovalProtector and see if that helps?

So destroying Nodes during synchronous events fired during a DOM mutation
> is significantly slower. This case is rare though. I had to think hard to
> come up with a case where we would hit this. For the most part, nodes don't
> actually get destroyed due to JS until a garbage collection occurs, which
> is usually after the event has completed and the DOMRemovalScope has been
> destroyed.
>

Do we know how common this happens in wild? How "rare" is it?

- Ryosuke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120301/5399ca6f/attachment.html>