Comments on: Benchmark: DOM vs. innerHTML

By: domguru

domguru — Sat, 19 May 2007 08:23:31 +0000

This test is a complete nonsense. why dont you guys append those DIV elements to the document and see which one is really faster. Speaking from experience, IE will be the clear winner if you appendChild right after createElement method. There is no browser out there which can beat Internet Explorer if you really know what you are doing.

By: DOM vs. innerHTML « ì›ƒìœ¼ë©° ì‚¬ëŠ” ì„¸ìƒ

DOM vs. innerHTML « ì›ƒìœ¼ë©° ì‚¬ëŠ” ì„¸ìƒ — Fri, 01 Dec 2006 04:27:52 +0000

[...] DOM vs. innerHTML Published October 19th, 2006 Enter the Matrix ì¶œì²˜: Ajaxian and code here [...]

By: David Friedland

David Friedland — Mon, 30 Oct 2006 22:57:44 +0000

After searching for many hours on trying to find a way to dynamically populate an enormous drop down list (up to 14k items). Nothing beats innerHTML. We’re talking dollars and cents here. It’s not rocket science. If innerHTML works in a fraction of a second and the DOM method takes 4 seconds, just do the math. The client makes $x per minute. and if they lose 3.5 seconds per user per list change, they’re not going to care how it’s coded, they’ll want innerHTML. Welcome to the real world. I just want an easier way to pop it into my elements where IE won’t try to parse it. Any ideas?

By: fdwflezcsk

fdwflezcsk — Wed, 25 Oct 2006 07:37:57 +0000

fwxrrjchu

kmpkkruy wzngfdy qypnplfqru

By: Luis Ortiz

Luis Ortiz — Thu, 19 Oct 2006 18:22:35 +0000

Totally agree with Richard Kimber. In practice, I have always used document.createDocumentFragment() to ameliorate the performance problems with complex DOM manipulation. At times though I have used innerHTML because its so simple (Chuck) but I always feel a little bit dirty for doing so - like fast food dinners.

By: Abe Pazos

Abe Pazos — Thu, 19 Oct 2006 11:33:28 +0000

About my post above, I asked Wladimir Palant, (main) author of Adblock Plus about the JavaScript performance and he told me this specific test creates lots of images, which Adblock Plus must check to see if they are ads or not, making it slower. It should not happen with typical JavaScript code.

By: Gleb

Gleb — Thu, 19 Oct 2006 06:59:25 +0000

Updated values from my benchmark:

MOZ

Result: node.innerHtml=… 397.0 404.0 406.0 255.9 413.0
Result: document.createElement(‘… = 114.0 120.0 119.0 124.6 151.0
Result: document.cloneNode(‘… = 122.0 115.0 120.0 122.3 150.0

IE 32 + AOL Toolbar

Result: node.innerHtml=… 101.0 89.0 85.0 95.0 90.0
Result: document.createElement(‘… = 30.5 30.0 29.5 29.0 28.0
Result: document.cloneNode(‘… = 40.0 38.4 38.0 36.0 35.0

IE 64

Result: node.innerHtml=… 160.0 147.0 118.0 90.0 57.1
Result: document.createElement(‘… = 34.4 32.0 29.6 35.0 40.4
Result: document.cloneNode(‘… = 37.4 36.4 35.0 32.5 29.0

Opera

Result: node.innerHtml=… 1901.0 941.0 1300.3 9.0 1919.0
Result: document.createElement(‘… = 320.0 327.8 330.7 336.0 331.0
Result: document.cloneNode(‘… = 344.0 348.0 360.0 347.0 350.0

Opera is still the fastest, but there is no big diffenece between createElement and cloneNode…

By: Gleb

Gleb — Thu, 19 Oct 2006 05:28:22 +0000

This code is based on my HTML2DOM converter used to create DHTML forms. So controlContainer is legacy :)

By: Steve

Steve — Wed, 18 Oct 2006 22:22:38 +0000

Is there really much point to this? Unless you’re doing some incredibly unusual dynamic building of pages, you’re typically just inserting a handful of elements in response to an event and *either* approach is going to be fast enough.

By: Chuck

Chuck — Wed, 18 Oct 2006 20:11:32 +0000

The simplification and convenience of innerHTML just can’t be beat. If you’re inserting content that fits a very rigid structure, you may not need it, but if you’re creating functions with a wide degree of flexibility, manual DOM methods can be hell.
You create a method that displays a confirmation message. Then you realize that you need to be able to display messages that occupy multiple paragraphs. Hmmm… Or even just throw in simple stuff like the need to include inline tags (em, strong, etc.).
Sure, you can create a parsing system of your own, but there’s no way you can possibly create one better than the compiled one built in to the browser and certainly nothing that can be implemented as easily as foo.innerHTML=bar.

By: Abe Pazos

Abe Pazos — Wed, 18 Oct 2006 17:55:13 +0000

It looks like Adblock Plus makes the test results much worse:
FIREFOX 1.5.0.7 – NO Adblock
. Inner HTML: 512 514 516 513
. document.createElement: 169 164 165 164
FIREFOX – Adblock Plus 0.7.1.2 disabled in interface
. Inner HTML: 204 207 204 207
. document.createElement: 117 115 117 115
FIREFOX – Adblock Plus 0.7.1.2 Enabled
. Inner HTML: 171 166 165 155
. document.createElement: 111 118 113 105
OPERA 9.0 beta
. Inner HTML: 2800 2580 2635 2549
. document.createElement: 240 229 184 232
IE 6
. Inner HTML: 317 269 247 227
. document.createElement: 98 80 72 68

Does it mean JavaScript executes 3 times slower with Adblock Plus installed on Firefox? Or maybe only certain operations?

By: ndp

ndp — Wed, 18 Oct 2006 16:24:17 +0000

Speed is usually not the critical factor for code– at least 90 – 95% of it– so I can’t see how you can make architectural decisions solely on this benchmark, whether it’s valid or not.

If I’m reading it right, the slowest code only takes 1/60th of a second, and has no affect on my server, where the bottlenecks usually are.

You can argue that this is a very simple page, and real pages are more complicated. In reality, though, the page complexity is bounded by what a user can comprehend, so it’s not going to be more than an order of magnitude more complicated. So for the most complicated reasonable page, we’re talking 1/6th of a second vs. 1/20th of a second (FF), and less of a difference on IE. These both seem within the realm of a “responsive” app.

By: Isaiah

Isaiah — Wed, 18 Oct 2006 16:01:17 +0000

Not all DOM selection techniques are created equal. Here’s a LIVE benchmark that you can run yourself to see how the various Javascript frameworks handle it.

http://wiki.mootools.net/benchmark

Isaiah

By: Patrick Corcoran

Patrick Corcoran — Wed, 18 Oct 2006 15:53:57 +0000

Why is he adding all those custom node attributes called “controlContainer”?

They are not part of any spec, the browser doesn’t need them, and they can only be slowing down the generation of his DOM creation.

By: Henrik Gemal

Henrik Gemal — Wed, 18 Oct 2006 15:43:47 +0000

Using latest nightly Mozilla Firefox builds Im getting numbers like:
test1: 133
test2: 129

So next gen Firefox will be much faster than todays

By: Richard Kimber

Richard Kimber — Wed, 18 Oct 2006 15:34:44 +0000

It seems to me that both methods have there advantages and disadvantages. I took it for granted that the innerHTML option would be a lot faster (to write as well, in some cases), however DOM offers more structured control of individual elements. I don’t really see what all the fuss is about.

By: Mark Kahn

Mark Kahn — Wed, 18 Oct 2006 15:29:45 +0000

I agree with VoR in that this is often more about ease of use than it is about speed. To me, having direct references to specific DOM nodes is often a necessity. I’d be interested in seeing this same benchmark, but with this instead:

x.innerHTML = ‘….’;
var node1 = document.getElementById(‘node1′);
var node2 = document.getElementById(‘node2′);
…etc

so that you can get actual references to all the nodes you just created.

Granted, you often don’t NEED references to every single node, but the code isn’t doing the same thing otherwise!

By: Andrew Herron

Andrew Herron — Wed, 18 Oct 2006 15:09:02 +0000

The only time I use innerHTML is to pull the data inside an element, that way I don’t have to deal with FF’s textNodes.

By: Scott Schiller

Scott Schiller — Wed, 18 Oct 2006 14:58:41 +0000

I wouldn’t consider this to be a valid comparison, given innerHTML modifies the DOM once with a large string, whereas using createNode() and so on, 95 nodes are made; of course the “standard” method will be slower with that approach! :) .. Were one cloneNode() and one append to be used, I would expect you’d see similar results. When the browser has to individually create 95 nodes as with this “test”, there should be no question as to which method will be faster.

Secondly, I’m of the opinion that it is poor practice to be creating mass amounts of markup using Javascript. Instead, one should use a “templating” approach – have your HTML where it should belong to begin with (in the document as HTML), clone it once and append to a target once (or clone many times to a document fragment, and append that fragment once) as opposed to creating it all in Javascript.

With the new Yahoo! Photos, the cloning approach was taken to creating mass amounts of photo items using Javascript, and it has worked quite well. It is slightly slower than innerHTMLing a super-large string out, but I’ve found the standard DOM-based approach is easier to work with and maintain. If you don’t do multiple (or many) writes to the DOM (ideally just one like innerHTML), your performance should be quite comparable.

By: Gleb

Gleb — Wed, 18 Oct 2006 14:53:25 +0000

Hi, all!

Really the test was not about DOM vs. innerHTML, so it is valid. I think DOM can be optimized, but whole idea of this benchmark was to measure javascript+dhtml performance, not dhtml technique performance ;-)

So, Mario, you think cloning will be much faster? Can you give me a sample how I can use it on my JavaScript?

Comments on: Benchmark: DOM vs. innerHTML

By: domguru

By: DOM vs. innerHTML « ì›ƒìœ¼ë©° ì‚¬ëŠ” ì„¸ìƒ

By: David Friedland

By: fdwflezcsk

By: Luis Ortiz

By: Abe Pazos

By: Gleb

By: Gleb

By: Steve

By: Chuck

By: Abe Pazos

By: ndp

By: Isaiah

By: Patrick Corcoran

By: Henrik Gemal

By: Richard Kimber

By: Mark Kahn

By: Andrew Herron

By: Scott Schiller

By: Gleb

By: DOM vs. innerHTML « ì›ƒìœ¼ë©° ì‚¬ëŠ” ì„¸ìƒ