zlacker

As a JavaScript developer my priorities are limited to visual render and DOM access. Going back 5+ years ago Chrome was able to access the DOM at about 45m ops/s on my desktop and Firefox was achieving about 850m ops/s on the same hardware. On my laptop (faster memory) Chrome was getting up to 55m ops/s while Firefox was around 1.4b ops/s.

Now Firefox numbers have remained constant, but Chrome struggles to hit 20m ops/s in my desktop. Chrome has sacrificed front end performance across the board for modest performance improvements to query string access of the DOM. Pretty unfortunate.

>>austin+(OP)
How many cores was laptop benchmark running on?

>>kstrau+Jv
I believe the CPU is 4 core, JavaScript is single threaded (multi-callstack) so you only get 1 logical CPU core.

>>austin+(OP)
"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.

>>austin+tW
I thought so, but wasn't sure.

That makes me super suspicious of 1.4B op/s. Surely Firefox isn't accessing the DOM in ~2 CPU cycles?

>>kstrau+Co1
Appears to be: https://jsbench.github.io/#b39045cacae8d8c4a3ec044e538533dc

Its just a crude memory operation for Firefox. The video card in my laptop is super inferior compared to my desktop, so in most other benchmarks the laptop is much slower. The laptop has DDR4 memory where the desktop has slower DDR3 memory.

>>magica+Cl1
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+uF1
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)