On Thu, Mar 1, 2012 at 4:50 PM, Ojan Vafai <[email protected]> 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
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
