Re:innerHTML vs. appendNode vs. DocumentFragment, for mobile
by emn13 on Monday May 19, 2014 @04:29PM
(#7769569)
JsPerf is really well known, but unfortunately, it also very poorly suited for this kind of performance comparison:
1. JSperf doesn't encourage any kind of validation that the various snippets actually do the same thing. I'm not kidding when I say that almost all jsperfs I read are buggy. This one is too; it reuses the same pre-cached nodes without cloning them, and those aren't semantics you want and aren't comparable with innerHTML.
2. JSperf's scaling is terrible. It's showing ops/sec rather than sec/ops, when the latter is much more interesting. Almost always you're interested in keeping UI latency low, not in somehow repeating as many operations per second; the ops/sec display emphasizes tiny differences that don't matter over very large differences that do. A difference in 0.01s vs 0.011s will appear just as large as (say) 0.1s vs. 1s, and that's not helpful. A logarithmic scale might be nice too.
3. JSperf's semantics are surprising enough to cause bugs. For instance, the benchmark setup/teardown aren't called for every test, nor are they merely called before the first and after the last test - but something utterly useless in between. Tests aren't isolated from each other, so cruft left from one test can impact a later test easily. Actually, tests are run in the jsperf document itself, so trivial stuff like how many comments or versions a benchmark has could conceivably impact DOM performance.
It can still be a useful tool - but be aware that most jsperfs out there are quite misleading because they don't test what they claim.
1. JSperf doesn't encourage any kind of validation that the various snippets actually do the same thing. I'm not kidding when I say that almost all jsperfs I read are buggy. This one is too; it reuses the same pre-cached nodes without cloning them, and those aren't semantics you want and aren't comparable with innerHTML.
2. JSperf's scaling is terrible. It's showing ops/sec rather than sec/ops, when the latter is much more interesting. Almost always you're interested in keeping UI latency low, not in somehow repeating as many operations per second; the ops/sec display emphasizes tiny differences that don't matter over very large differences that do. A difference in 0.01s vs 0.011s will appear just as large as (say) 0.1s vs. 1s, and that's not helpful. A logarithmic scale might be nice too.
3. JSperf's semantics are surprising enough to cause bugs. For instance, the benchmark setup/teardown aren't called for every test, nor are they merely called before the first and after the last test - but something utterly useless in between. Tests aren't isolated from each other, so cruft left from one test can impact a later test easily. Actually, tests are run in the jsperf document itself, so trivial stuff like how many comments or versions a benchmark has could conceivably impact DOM performance.
It can still be a useful tool - but be aware that most jsperfs out there are quite misleading because they don't test what they claim.