zlacker

>>akyuu+(OP)
See also https://arewefastyet.com.

>>e4m2+p6
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+MR
"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+od2
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