| sitelink1 | |
|---|---|
| sitelink2 | |
| sitelink3 | http://1 |
| sitelink4 | http://ko |
| extra_vars5 | http://www.quirksmode.org/dom/innerhtml.html |
| extra_vars6 | sitelink1 |
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.
Experiments
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 |
140 ms 140 ms 141 ms |
140 ms | 933 | 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 |
125 ms 128 ms 124 ms 128 ms 119 ms |
125 ms | 833 | 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 |
139 ms 129 ms 124 ms 125 ms |
129 ms | 860 | 6500 | 9300 | 350 | 220 | 250 | 350 | 250 | |
| The next experiment uses the W3C DOM table methods. | |||||||||||
|
innerHTML 1 Concatenate a string Test now |
15 ms 15 ms 15 ms 15 ms |
15 ms | 100 Fastest script |
175 | 180 | 110 | 100 | 120 | 100 | 225 | |
|
innerHTML 2 Push strings into array, then join array
Test now |
17 ms 17 ms 15 ms 16 ms |
16 ms | 107 | 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 |
Absolute numbers
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:
- Opera: 20 ms (unchanged)
- Explorer 6: 67 ms
- Explorer 5: 83 ms
- Mozilla:
145 ms116 ms
Mac:
- Explorer: 228 ms
- Mozilla: 340 ms
- Safari:
581 ms593 ms - iCab: 7,500 ms
Discussion
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.
Explorer Windows
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
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
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
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.
Safari
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).
iCab
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.
