<div class="gmail_quote">On Thu, Mar 1, 2012 at 4:50 PM, Ojan Vafai <span dir="ltr"><<a href="mailto:ojan@chromium.org" target="_blank">ojan@chromium.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


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.</blockquote>


<div><br></div><div>This sounds like a nice feature.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>I uploaded two performance tests to that bug:</div>


<div>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.</div>

<div>2. Destroy half a million nodes *during* a synchronous event (uses range.deleteContents). Goes from ~284ms to ~342ms. A 20% regression.</div></blockquote><div><br></div><div>I'm surprised that we get a 20% regression. Can we try inlining all functions in DOMRemovalProtector and see if that helps?</div>


<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>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.</div>


</blockquote><div><br></div><div>Do we know how common this happens in wild? How "rare" is it?</div><div><br></div><div>- Ryosuke</div><div><br></div></div>