Benchmark - W3C DOM vs. innerHTML

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.

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.

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.

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 ms 116 ms

Mac:

Explorer: 228 ms

Mozilla: 340 ms

Safari: 581 ms 593 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.

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 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.