[Webkit-unassigned] [Bug 6718] deep appendChild is too slow! (Safari wins on all but one JavaScript microbenchmark)

bugzilla-daemon at opendarwin.org bugzilla-daemon at opendarwin.org
Mon May 22 13:53:20 PDT 2006


------- Comment #1 from safari at keeto.net  2006-05-22 13:53 PDT -------
According to Shark, appendChild is spending all it's time in 
RenderContainer::removeLeftoverAnonymousBoxes(). It's not necessarily due to a
deep DOM tree, though. I was able to get numbers for this by appending a
relatively small subtree a large number of times.

My test setup uses the DOM API in Cocoa directly. It iteratively creates a
small group of elements DIV( P(textNode) INPUT(textNode) ) and appends that to
the BODY element in a loop. It then removes everything with [body

It's spending all of it's time in the removeLeftoverAnonymousBoxes() routine,
recursively walking up the tree on every call - and it gets called again for
each sibling in both directions as each element is added. My understanding of
that routine is that it's coalescing any anonymous boxes from neighboring
inline elements, as the spec dictates. It just seems to be going about it in a
terribly inefficient manner - especially considering none of this ever actually
gets rendered to the screen.

I've varied the number of iterations from 100 to 500000 - and performance falls
off dramatically as soon as you start getting VM faults. Not really surprising,
really, but it effectively makes doing anything remotely complex in terms of
DOM/AJAX/Web2.0/Whatever unworkable in Safari. To be fair, Firefox isn't
exactly a Ferrari, but it's about an order of magnitude faster than Safari at
this task.

To be thorough, I duplicated this test in pure Javascript and executed it from
my test application as well (using evaluateWebScript:) with roughly the same
results. I expected this as both implementations end up calling into the same
WebKit code, but I wanted to be thorough.

Configure bugmail: http://bugzilla.opendarwin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

More information about the webkit-unassigned mailing list