[webkit-dev] scoping Node destruction during DOM modifications

Adam Barth abarth at webkit.org
Thu Mar 1 17:06:52 PST 2012

Do we understand what's causing the performance regression?  For
example, there are other implementation approaches where we try to
transfer the last ref rather than churning it or where we could use a
free list rather than a vector.  I just wonder if there's a way to get
the benefits with a lower cost.


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.
> Currently, we need to write careful code that knows whether any methods it's
> calling can fire sync events and RefPtrs all the appropriate nodes. I have a
> proposal to automate this in https://bugs.webkit.org/show_bug.cgi?id=80041.
> It certainly makes the code cleaner and safer, but it comes at a performance
> cost in some cases.
> Basically, any scope that needs to be careful of sync events adds a
> DOMRemovalScope at the top which keeps nodes from getting destroyed until
> the scope is destroyed (DOMRemovalScope adds them to a
> Vector<RefPtr<Node>>). In cases where we don't delete nodes, there's no
> performance impact. In cases where we delete nodes, this is always slower.
> 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.
> 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.
> The advantage of this is that it gives a simple way to address a common
> class of crash and potentially security bugs. The disadvantage of course is
> the possible performance hit.
> What do you think? Is this worth trying? Are there better ideas?
> Ojan
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

More information about the webkit-dev mailing list