Re: More Ideas around DOM Constructors

On 11/20/09 12:17 PM, Jeff Schiller wrote:
> There are a variety of ways that DOM elements can be constructed.  In
> HTML land, there are pretty much two ways:  DOM Level 1 and
> innserHTML.  It seems that many browsers (IE, Mozilla, Opera) have
> optimized using innerHTML

Just a a matter of record ... sort of.

Browsers have optimized _parsing_ for obvious reasons: it's used during 
pageload.  And it allows some optimizations that DOM manipulation is not 
really amenable to right now (e.g. in Gecko when parsing we know how 
many attributes the element will end up before creating the element with 
so preallocate the memory for them instead of having to realloc as 
needed on each attr set).

But at least in Gecko one of the main reasons for the observed 
performance difference is that the test is comparing apples and oranges. 
  Two obvious instances of that for this test in Gecko:

1)  Insertion into the DOM.  The innerHTML test you link to
     inserts all the new nodes as a single DocumentFragment insertion
     in Gecko; the DOM test you link to does not.  The former is more
     efficient, since it allows coalescing of various work that needs
     to happen on insert.  If the DOM test used a document fragment,
     that would change the numbers somewhat.
2)  Which objects are being created.  In Gecko, the innerHTML test
     you link to creates a strign and a bunch of C++ DOM objects.
     The DOM test creates a bunch of C++ DOM objects and a bunch of
     reflections of these into JavaScript.  This last is a noticeable
     cost.  You can change the test to actually touch all the resulting
     objects in the innerHTML test to be closer to an apples-to-apples
     comparison, but it might be that you don't in fact care about
     those JS reflections; in that case the test is actually measuring
     what you want to measure.

Now obviously innerHTML has the extra overhead of parsing, so the 
comparison will always be a little odd; you're trading off some types of 
extra work for other types...

> createElement("circle", {cx: 40, cy:40, r:20, fill:"red"})
...
> This reduces the number of DOM calls by N.

But increases the amount of work the createElement implementation has to 
do.  It's not obvious to me where the performance tradeoff here would 
lie, actually, even in Gecko.

I do think this API has one obvious thing to recommend itself, which is 
being nicer to read than a bunch of setAttribute calls (plus maybe 
allowing the attribute-count optimization I noted above, I guess).

-Boris

Received on Friday, 20 November 2009 18:10:51 UTC