Section 8F of the book discusses innerHTML and when it's preferable
to "real" W3C DOM methods.
This is a test page intended to find out which method of generating large amounts of content is fastest in the browsers. Of course the results differ significantly from browser to browser.
Each of the test scripts creates a 50x50 table, all of whose cells are filled with one character, *.
Then the time your browser needs is measured and compared to the time it needed to execute the other methods.
Key:
| 100 | Fast | OK | Slow | Very slow |
| index 100 | index 101-200 | index 201-500 | index 500-5000 | index 5001+ |
I did each test 5 times, and then used the index values for judging the relative speed of the various methods.
I added the rough index for each script. Of course the fastest script has index 100 by definition.
| Method | Time | Average time | Index | IE 5.5 | IE 6 | IE 7 | FF 2 | FF 3b3 | Safari 3.0 Win | Opera 9.5b | Konqueror 3.5.7 |
|---|---|---|---|---|---|---|---|---|---|---|---|
|
W3C DOM 1
Create all elements as they're needed
Test now |
310 | 3600 | 300 | 270 | 300 | 390 | 350 | ||||
| Earlier experiments clearly show that the fastest way to generate the table with pure W3C DOM methods is to use as little intermediary variables as possible and to append the table only after it has been created completely. | |||||||||||
|
W3C DOM 2
Create elements once, then clone
Test now |
275 | 3500 | 275 | 185 | 275 | 340 | 160 | ||||
The next experiment creates only one tr element, one td element
and one text nodes and clones them as often as necessary.
|
|||||||||||
|
Table methods
Use W3C DOM table methods
Test now |
6500 | 9300 | 350 | 220 | 250 | 350 | 250 | ||||
| The next experiment uses the W3C DOM table methods. | |||||||||||
|
innerHTML 1
Concatenate a string
Test now |
175 | 180 | 110 | 100 | 120 | 100 | 225 | ||||
|
innerHTML 2
Push strings into array, then join array
Test now |
100 | 100 | 110 | 100 | 115 | 100 | |||||
Natively Explorer 5 doesn't support the push method. My quirksmode.js
file contains functions that mimic this behaviour, though. The test uses these functions.
|
|||||||||||
| Method | Time | Average time | Index | IE 5.5 | IE 6 | IE 7 | FF 2 | FF 3b3 | Safari 3.0 Win | Opera 9.5b | Konqueror 3.5.7 |
Below you find the execution times of the fastest scripts in each browser. Of course these numbers depend heavily on the computer you use, so I doubt you'll find the same values when you perform the tests.
Windows:
Mac:
The most obvious conclusion of these tests is that innerHTML is faster than "real" W3C DOM
methods in all browsers. The W3C DOM table methods are slow to very slow, especially in Explorer.
More than once people said that creating elements only once and then cloning them when necessary leads to a dramatic performance improvement. These tests don't show anything of that kind. Although in most browsers cloning is minimally faster than creating, the difference between the two methods is small.
What amazes me most is the huge difference between Explorer 5 and 6. Although 6 executes the innerHTML scripts slightly faster than 5, it is incomparably slower in executing all other scripts. Where 5 shows an index number of around 300 for the "real" W3C DOM scripts, 6 shows an index of about 3000! Maybe this is caused by my running multiple Explorers on one computer, I don't know. Explorer 5.5 is quite close to 5.0.
According to a reader, Explorer 6.0 needs more time for every row it adds, so that if I'd create a table with 100 rows, all other browsers would require about twice the time they need now, but Explorer 6 would take far more time. This explanation fits the available data, though I'm not sure why the Explorer team would have done this.
Explorer 7 beta 3: Little change. The slow methods appear to be slightly slower than in 6.
Mozilla 1.4: Rather to my surprise Mozilla is the slowest browser on Windows when we compare its fastest script to the fastest scripts of the other browsers. On the other hand it shows the least difference between the methods, its slowest script is only 3 times slower than its fastest.
Changes for Mozilla 1.75: Has become marginally faster, and the two innerHTML methods have traded places: now the push-innerHTML method is marginally faster than the concatenation-innerHTML method.
Opera 7.20 is by far the quickest browser on Windows, leaving Explorer and Mozilla to eat its
dust. Although its slowest script has an index of about 450, it's still faster than Mozilla's fastest script
and roughly equal to Explorer fastest script.
Opera's performance has changed considerably since I did my earlier experiments.
Then the W3C table methods were fastest, now they're the slowest method.
Changes for Opera 8: The slow methods have become marginally slower. Overall there's little change, and Opera remains by far the fastest Windows browser.
Changes for Opera 9: The slow methods have once again become marginally slower when compared to the fastest.
Explorer Mac is a very slow browser when it comes to W3C DOM scripts. Its good score on the innerHTML tests surprises me. When we try anything else, though, Explorer Mac becomes mired in its bad W3C DOM implementation. It takes about 20 seconds to execute any "real" W3C DOM script, coming to a huge index of more than 9000.
Although Safari 1.0 keeps up very well, I noticed that it becomes gradually slower when you perform a test more than once. I suspect there's still a slight bug somewhere (garbage collection?) that causes its performance to degrade over the long run. On the other hand, it might be a problem of my specific Safari install.
Changes for Safari 1.3: Especially W3C DOM method 1 becomes much, much slower when you run the test twice or
more. My own test figures for W3C DOM 1: 430, 1258, 2182, 3129 and 4058 ms. As you see Safari grinds down rather in a hurry.
Other than that the difference between the methods is becoming larger. Safari 1.0 had a Fast score for
W3C DOM 1 and 2 (ie. not more than twice as slow as the fastest method), but in 1.3 they
have slowed down to 3 or 4 times as slow as the fastest method. The concatenation-innerHTML method has speeded
up remarkably, though. Where in 1.0 it was the slowest method (3 times as slow), it has now climbed to 1.8
times as slow. W3C DOM 1 is now the slowest method (index 373).
Extremely slow. This is clearly something that has to be improved in a future version. In addition, the more tests you do the slower the scripts become.