Deep cloning vs setting of innerHTML: what's faster?
Solution 1
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(/ jQuery\d+="(?:\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.
Solution 2
Hmmm... interestingly, I just did a test in Firefox 3, and a deep clone seems to be about 3 times faster than going the innerHTML route.
I'm sure innerHTML is still faster than individual DOM operations, but at least for deep cloning, cloneNode(true) seems to be better optimized.
levik
Updated on June 12, 2022Comments
-
levik almost 2 years
I'm trying to figure out the most performant way of deep-cloning a DOM tree within the browser.
If I start out with
var div = document.getElementById("source"); var markup = div.innerHTML;
What will be faster,
var target = div.cloneNode(true);
or
var target = document.cloneNode(false); target.innerHTML = markup;
I understand the browser platform may make a big difference here, so any information about how these compare in the real world would be appreciated.
-
user3167101 about 14 yearsGreat answer Bobince. Just wondering, what would be the best way to drop off these extra attributes? Searching only within angle brackets from a whitelist of HTML elements, or making a DOM element and then using jQuery's
removeAttr()
on it? Perhaps it's a trade-off, it might be much faster at the expense of mangling anyone that uses that string. Although it is rare, there should be some sort of warning in the jQuery docs (I haven't found it if there is) -
Amit Patil about 14 yearsWhat I'd do would be to set a JS property for the ID instead of an HTML attribute. IE has a bug where properties are serialised as if they were attributes, but it only kicks in where the property value is a primitive datatype. Object-type properties aren't included in the
innerHTML
. So settingelementnode.jQueryId45438= [1]
(an Array object) would allow jQuery to put its unique ID on the element without messing up the serialisation and requiring any post-innerHTML
fixups. -
Amit Patil about 14 years(Actually personally I'd prefer not to be adding identifiers to element nodes at all, but jQuery relies on the ability quite heavily.)
-
user3167101 about 14 yearsHey thanks for getting back to me. For what reason does jQuery add these extra attributes? I've noticed them in Firebug before.
-
Amit Patil about 14 yearsIt's essentially in order to decouple the element nodes from element data. This allows for data (including function/object references) to be associated with nodes without the risk of forming reference loops that leak memory in IE6-7. jQuery sets an ID attribute on the element, then looks up the same ID in a mapping (
jQuery.cache
) to get associated data. Event handling relies on a type of associated data, so pretty much every jQuery script is using this. -
user3167101 about 14 yearsWow! You really know your jQuery. Last time I looked at the source (a few years back) I didn't know much of what was going on!
-
CodeFinity almost 4 years"IE is, as expected, a dog." 🤣