performance test of DOM operations via innerHTML

Question

According to spirit of stackoverflow (thanks to @Bill the Lizard clarifying this) I would like to introduce small own research of the well known to all front-end web developers question.

How to get better performance of jscript while programming DHTML, using innerHTML or DOM operations?

For the testing I have created single HTML page with “start test” button that runs 5000 times pair of function, that is written either on innerHTML ideology, or by DOM. (It can be taken on: http://codepad.org/HyiKRsNk )

• To avoid compare CPU result are displayed in percent, how one of function is faster then another. So if you see (17%) it is mean that DOM faster innerHTML, if (may be latter) you see (-5%) it is mean innerHTML faster than DOM.
• To avoid effect of memory blow-up, for each call new "test area" is created and deleted immediately after test (time for creation/deletion is not encountered).
• Test are performed under display:none div to avoid flipping and performance degradation on scrolling

I have prepared 3 test (the last one proposed by @tomdemuyt)

1. create new DIV and child text for it

2. remove some DIV (to avoid influence of creation difference, both tests uses same way to create test div, but different for removing)

3. adding onclick event handler

4. Test creation of tree in depth, test create <table><tbody><tr><td><span>text construction. DOM test uses sequential calls of pair createElement/appendChild

5. Similar as (4) but 2 rows <tr> are created. DOM uses special helper function to simplify:

   treeHelper("table", 
       treeHelper("tbody", 
           treeHelper("tr", 
   

Test results are followed for different browsers.

So dear colleagues please provide: show some test when innerHTML is faster, start my test on non-listed-yet browsers.

Answer 1

Opera (10.54):

Test                                Result 
1.insert new element and text         30.00%
2.removeChild vs innerHTML=''         66.67%
3.set event handler                   245.45%
4.test in depth of tree linear        -62.16%
5.test in depth of tree (using helpr) -67.10%

Chrome (5.0.375.70):

Test                                 Result
1.insert new element and text          318.18%
2.removeChild vs innerHTML=''          53.85%
3.set event handler                    150.00%
4.test in depth of tree linear         41.67%
5.test in depth of tree (using helpr) -33.03%

FireFox(3.6.4):

Test                                  Result
1.insert new element and text           76.17%
2.removeChild vs innerHTML=''           50.56%
3.set event handler                     1097.44%
4.test in depth of tree linear          32.94%
5.test in depth of tree (using helpr)   9.66%

IE(8):

Test                                  Result 
1.insert new element and text           46.92%
2.removeChild vs innerHTML=''           26.34%
3.set event handler                     936.17%
4.test in depth of tree linear          -35.42%
5.test in depth of tree (using helpr)   -67.26%

EDITED(1): Added for each browser 2 lines with test of building tree in depth (test in depth of tree linear, test in depth of tree (using helpr)). It was discovered that most browsers don't like stack allocation values, since linear appendChild, appendChild... much faster then doing the same over treeHelper('table', treeHelper('tbody', ....

Answer 2

Based on the comments on the original question I'm adding an answer here that elaborates on why a straight up .innerHTML to DOM manipulation comparison is very hard to concisely evaluate.

Essentially there are a few major concerns:

1. Browser bugs & missing implementations
2. Content differences (what works better in case A, may not be better in case B)
3. Timing issues (JavaScript has no control or insight as to when the browser decides to do GC (Garbage Collection) or run other threads/activities

1.) In particular IE(6,7 & to a lesser extent 8) has a bunch of browser bugs that cause full testing of all code scenarios. (IE has bugs and can't set the .innerHTML on a select, table, thead,tbody,tfoot,tr, empty elements with overflow set to auto where the content is more than 1 "row" in height, pre elements where the content contains important whitespace etc.)

2.) The quantity, type (order) and depth of child nodes added will alter the performance of the operation. E.g. adding a table by adding the table tag, then a tbody, then a tr, then a td, then content vs. building this up separately and dumping it into the page will alter the performance.

3.) The browser controls when it does a GC (which will slow the browser for a moment while it does cleanup). Likewise a browser extension, or AJAX call in another tab, web slice in IE8 polls a server for updates it will affect how your current page performs.

Thus if you want to fully test this, you'd need to test several different combinations of HTML sub-structure and I would highly expect that the results will vary.

I have some old tests for this kind of thing at home that I'll dig up and add to this answer for more involved testing.