zlacker

"access the DOM" is not a constant operation, though, it will vary wildly based on what you're doing and what you were doing just before that (think of reading a computed style before vs after writing a style that forces layout).

1.4b ops/s also sounds like it might not be testing what you think it's testing. Access in that case might just be hitting a cache, so possibly not at all representative of real performance of a web app.

>>magica+(OP)
No, the DOM is a living artifact, but it lives in memory. So access to the DOM, at least for Firefox, appears to just be a crude memory operation of walking a tree from a narrow collection of pointers in the JIT.

https://jsbench.github.io/#b39045cacae8d8c4a3ec044e538533dc

>>austin+Sj
I mean, these aren't just any access of the DOM, they're specifically selectors on the DOM (with a few stepping into children and then running selectors on them). So that does narrow the original claim significantly.

I also see five orders of magnitude between the fastest and slowest operations there (`document.getElementById("canvas")` vs `document.getElementsByAttribute("href")`) on my machine, so it's not clear what you're disagreeing with my comment about.

On my machine, Chrome is slower by an order of magnitude on the first three tests, but is approximately the same (slightly faster or slower) on the rest. And I'll still assert these microbenchmarks aren't testing anything meaningful. Millions of calls to `document.getElementById("canvas")` in a loop is almost certainly just hitting a cache, which is fine but also reveals little about how it will affect execution of actual scripts (is the querySelector even a bottleneck in a particular piece of code? how big is the cache vs the actual uses before a `document.getElementById("canvas")` comes back around again? etc)