using the DOM API to flatten to XHTML instead of a DOM tree

[Carl Shimer]

Hi,

 

It has been well documented that the native DOM API’s are slower than manipulating straight XTHML – see http://www.quirksmode.org/dom/innerhtml.html for a discussion of this issue.  In the spirit of not optimizing for performance up front I have been ignoring the DOM speed and using the Mochikit DOM creation APIs.  However, during recent hotspot analysis I found that I can dramatically speed up my code by replacing the Mochikit DOM creation APIs with hand generated XHTML and applying the generated string directly to the innerHTML value. 

 

Contrived example:

 

Results = []

for(var i=0;i<50;i++) {

      results.append(‘<p>’);

      results.append(‘lorem ipsum blah blah’);

      results.append(‘</p>’)

}

getElement(‘container’).innerHTML = Results.join(‘’)

 

This is much faster than doing something like this:

 

var el = getElement(‘container’);

for(var i=0;i<50;i++) {

el.appendChild(P(null,’lorem ipsum blah blah’));
}

           

I know the above is example is somewhat flawed because it is faster to build all the nodes at once and add to the tree in one operation rather than 50 ops.  However, that’s not the point – the point is that the Mochikit DOM api’s are much more pleasant than manipulating strings directly.  I am wondering if it might be feasible to come up with an approach that would use the same API format but perhaps use an alternative “flattener” that could generate XHTML instead of a DOM tree.  Thoughts?

 

Carl

[Bob Ippolito]

On Nov 14, 2005, at 6:47 PM, Carl Shimer wrote:

It has been well documented that the native DOM API’s are slower than manipulating straight XTHML – seehttp://www.quirksmode.org/dom/innerhtml.html for a discussion of this issue.  In the spirit of not optimizing for performance up front I have been ignoring the DOM speed and using the Mochikit DOM creation APIs.  However, during recent hotspot analysis I found that I can dramatically speed up my code by replacing the Mochikit DOM creation APIs with hand generated XHTML and applying the generated string directly to the innerHTML value. 

I'm well aware of that, but MochiKit is currently designed for rapid development and not performance.  The DOM APIs are the most convenient way to come up with functionality that works correctly, so that's what MochiKit uses.  What you're asking for isn't really possible, directly, with the current MochiKit.DOM API because all of the createDOM functions actually return an element as-is, not a "promise to create an element".  innerHTML is pretty nasty, and I'd really rather just see browsers get better at DOM than resort to using hacks.  However...

In theory, the way to do this without mucking everything up would be do come up with a set of mock objects that act like DOM nodes, use withDocument() and then have a way to serialize that... for example, take a look at the MockElement stuff at the end of the MochiKit.DOM tests <http://mochikit.com/tests/test_MochiKit-DOM.html>, which uses such a technique (minus the XHTML serialization).  You may still lose if the cost of working with these mock objects outweighs the cost of just using DOM, so don't spend too much time on it until you've profiled both methods.   

If someone writes this, I'll surely accept the patch... but I'm not planning to do it myself any time soon.  I suppose such a thing might also be useful for non-browser contexts because you'd have a nice little pure JavaScript way to do (write-only) XHTML.

-bob

[Bob Ippolito]

On Nov 14, 2005, at 7:03 PM, Bob Ippolito wrote:

On Nov 14, 2005, at 6:47 PM, Carl Shimer wrote:

It has been well documented that the native DOM API’s are slower than manipulating straight XTHML – seehttp://www.quirksmode.org/dom/innerhtml.html for a discussion of this issue.  In the spirit of not optimizing for performance up front I have been ignoring the DOM speed and using the Mochikit DOM creation APIs.  However, during recent hotspot analysis I found that I can dramatically speed up my code by replacing the Mochikit DOM creation APIs with hand generated XHTML and applying the generated string directly to the innerHTML value. 

I'm well aware of that, but MochiKit is currently designed for rapid development and not performance.  The DOM APIs are the most convenient way to come up with functionality that works correctly, so that's what MochiKit uses.  What you're asking for isn't really possible, directly, with the current MochiKit.DOM API because all of the createDOM functions actually return an element as-is, not a "promise to create an element".  innerHTML is pretty nasty, and I'd really rather just see browsers get better at DOM than resort to using hacks.

Oh, and isn't it invalid to use innerHTML in some contexts?  XHTML strict or something?

-bob

[Carl Shimer]

All my tests were done with

 

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"

 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

 

which seems to allow innerHTML.  And yes, using innerHTML does stink….

 

 

---

[Bob Ippolito]

On Nov 14, 2005, at 7:16 PM, Carl Shimer wrote:

All my tests were done with

 

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"

 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

 

which seems to allow innerHTML.  And yes, using innerHTML does stink….

I believe that the restriction only kicks in if you serve the document with the application/xhtml+xml Content-Type.  That may have changed, but I'm pretty sure that was the case for some builds of Mozilla.

-bob

[john]

Agreed. This is a bug in mozilla, but unrelated to any standards:
https://bugzilla.mozilla.org/show_bug.cgi?id=155723

I tested the link above, and IE is >10 times slower using the DOM!