[webkit-dev] scoping Node destruction during DOM modifications
rniwa at webkit.org
Thu Mar 1 17:13:37 PST 2012
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
Do we know how common this happens in wild? How "rare" is it?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev