outbreak

Me

My name is Marko Mrdjenovič. I’m a web developer, manager and an entrepreneur from Ljubljana, Slovenia.

Bio

I like solving problems. I do that by writing code, managing projects and people. I like creating good experiences. And going to conferences.

Availability

I work full time on Klevio so I'm currently not available for freelance work (UX, frontend, backend).

Elsewhere:
LinkedIn
Twitter
Facebook
Quora
Flickr

Archives

DOM DocumentFragments

As I read John‘s post on DocumentFragments the idea was very obvious as were the speed improvements.

Let’s say you have 10 divs that you attach to and 10 elements that you need to attach. In the “normal” case this means you will call appendChild 100 times and cloneNode 100 times. In the “fragment” case you will only call appendChild 20 times (10 to append the elements to the fragment and 10 to append the fragment to the divs) and cloneNode 10 times (when appending the fragment to the div). My thinking was that with clone you don’t really gain much as it in effect must clone 100 nodes even though it is called only 10 times, but you do gain some time with less appends and you might gain some more time by not appending each node to the visible document which should trigger less redrawing.

As I don’t like to be in the dark I set off to test some of these assumptions. I didn’t run the test in all browsers so Firefox 3 on Mac will have to do:

Append 10 nodes to a detached node
60us
Append 10 nodes to an attached node
360us
Append 10 nodes to an attached node, display:none
160us
Append 10 nodes to a fragment
60us

This means that appending does seem to be slower when you are attaching to nodes that are in the displayed document but also that appending to an element is no slower than appending to a DocumentFragment.

The next test I wanted to do is to see how speed of clone changes when you have the same number of elements in different depths:

Clone a detached empty node
15us
Clone an attached empty node
15us
Clone an empty fragment
15us
Clone an empty node (deep)
15us
Clone an empty fragment (deep)
15us
Clone a detached node with 9 subnodes (total of 10 nodes)
27us
Clone an attached node with 9 subnodes (total of 10 nodes)
29us
Clone a fragment with 9 subnodes (total of 10 nodes)
27us
Clone a detached node with deep subnodes (total of 10 nodes)
28us
Clone an attached node with deep subnodes (total of 10 nodes)
28us
Clone a fragment with deep subnodes (total of 10 nodes)
27us
Clone 10 detached empty nodes in a loop
95us

As you can see the changes in test times between similar variations aren’t significant. It does however pay off to clone bigger chunks of the tree with the deep parameter.

This means you should only gain by using DocumentFragment when you’re attaching many sibling nodes that don’t have a single parent node. A simple case for this would be when you’re attaching items (<li>) to an existing list. On the other hand if you are attaching a whole list you would not gain anything since what you could do is set up a list and clone the whole list and attach that:

Append 10 items to a single list (directly)
100us
Append 10 items to a single list (fragment first)
107us
Append 10 items to 10 lists (directly)
2000us
Append 10 items to 10 lists (fragment first)
570us

In the first case, when attaching to a single list, you actually lose time with the fragment first method because you first attach items to the fragment and then attach the fragment to the list. I must remind you that you don’t need to do any cloning here since you’re only attaching the items to a single list. This means no gain due to clone being faster on bigger chunks. The second case mimics the case that John presented in his post and the difference is obvious.

The lesson: if you’re about to attach a lot of sibling nodes into more than one location (in other words you’ll need cloning) it’s smart to use a DOM DocumentFragment for that.

Zemanta Pixie

Express your opinion