Let's test!

I added the following code to a copy of StackOverflow's Questions page (removing existing scripts first, and running from scratch with one of the timeit()s uncommented each time around, three runs of 100 ops:

function timeit(f) {

    var start= new Date();

    for (var i=100; i-->0;) {

        f();

    }

    return new Date()-start;

}



var c= document.getElementById('content');

var clones= [];



//alert('cloneNode: '+timeit(function() {

//    clones.push(c.cloneNode(true));

//}))



//alert('innerHTML: '+timeit(function() {

//    var d= document.createElement('div');

//    d.innerHTML= c.innerHTML;

//    clones.push(d);

//}))

Here are the results running on a VirtualBox on a Core 2 Q9300:

IE7

cloneNode: 3238, 3235, 3187

innerHTML: 8442, 8468, 8552



Firefox3

cloneNode: 1294, 1315, 1289

innerHTML: 3593, 3636, 3580



Safari3

cloneNode: 207, 273, 237

innerHTML: 805, 818, 786



Chrome1

cloneNode: 329, 377, 426

innerHTML: 2327, 2536, 2865



Opera10

cloneNode: 801, 791, 771

innerHTML: 1852, 1732, 1672

So cloneNode(true) is much faster than copying innerHTML. Of course, it was always going to be; serialising a DOM to text and then re-parsing it from HTML is hard work. The reason DOM child operations are usually slow is that you're inserting/moving them one-by-one; all-at-once DOM operations like cloneNode don't have to do that.

Safari manages to do the innerHTML op amazingly quickly, but still not nearly as quickly as it does cloneNode. IE is, as expected, a dog.

So, auto -1s all round to everyone who said innerHTML would Obviously Be Faster without considering what the question was actually doing.

And yes, jQuery uses innerHTML to clone. Not because it's faster though — read the source:

// IE copies events bound via attachEvent when

// using cloneNode. Calling detachEvent on the

// clone will also remove the events from the orignal

// In order to get around this, we use innerHTML.

jQuery uses Element.attachEvent() to implement its own event system, so naturally, it needs to avoid that bug. If you don't need to, you can avoid the overhead.

Off-topic aside: Then again, I think holding jQuery up as the pinnacle of Best Practice may be a bit mistaken, especially given the next line:

html.replace(/ jQueryd+="(?:d+|null)"/g, "")

That's right — jQuery adds its own arbitrary attributes to HTML elements and then needs to get rid of them when it clones them (or otherwise gives access to their markup, such as through the $().html() method). This is ugly enough, but then it thinks the best way to do that is processing HTML using a regular expression, which is the kind of basic mistake you'd expect more from naïve 1-reputation SO questioners than the author of the Second Coming Best JS Framework Evar.

Hope you didn't have the string jQuery1="2" anywhere in your text content, 'cos if so you just mysteriously lost it. Thanks, jQuery! Thus ends the off-topic aside.