2 ms·
hint: jsperf.com http://jsperf.com/appendchild-vs-documentfragment-vs-innerhtml/37 http://jsperf.com/appendchild-vs-documentfragment-vs-innerht... (scroll down
by frik 12y ago
hint: jsperf.com
http://jsperf.com/appendchild-vs-documentfragment-vs-innerhtml/37 http://jsperf.com/appendchild-vs-documentfragment-vs-innerht... (scroll down for the comparison chart!)
- emn13 12y agoJsPerf 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.