I'm getting about 2.5 bn op/s, which suggests this is rather down to the JIT's ability to elide microbenchmarking code.

Edit: Worth pointing out that the linked page runs on an eight year old version of the "benchmarkjs" package, which is described as a robust benchmarking package, but while the linked blog posts discusses some issues with JS benchmarking, how to trick the JIT into actually still running your NOPs is not discussed.

You make a couple of assumptions and I am not sure they are correct.

1. JIT's ability to elide microbenchmarking code

This can be easily debunked using a combination of DOM instructions and taking note of how dramatically the ops/s count drops and then comparing that difference in ops/s against the same difference from another browser like Chrome. If both browsers report wildly different base numbers but similar ratios then there is no cheating for micro-benchmarking numbers.

2. Worth pointing out that the linked page runs on an eight year old version of the "benchmarkjs" package

I found a different site that reports similar numbers so either they are using the same old code or the numbers valid without regard for the old code. https://jsbench.me/

> If both browsers report wildly different base numbers but similar ratios then there is no cheating for micro-benchmarking numbers.

I don't have a lot of experience with JS benchmarking, but for the JVM microbenchmarking is genuinely difficult and relatively worthless because the JIT is really good at killing off huge swaths of code if the results aren't used and side effects aren't observed. And even if you do, it's not unusual for it to optimize your code for the microbenchmark in a way that's not directly applicable to production use.

Unless the benchmarking code around this does some transformations on the source, I would expect a JIT (or an optimizing interpreter) to simply remove a side-effect-free statement. I would certainly expect a state-of-the-art JIT that's heavily bound to the DOM implementation to infer "document.getElementById("#foo");" is a NOP.

> This can be easily debunked using a combination of DOM instructions and taking note of how dramatically the ops/s count drops and then comparing that difference in ops/s against the same difference from another browser like Chrome.

To get back to your particular example, since getElementById in your microbench runs at approximately 100+ times the speed of querySelector (~15 mio op/s, which seems like what you'd expect) I would suspect that querySelector() is not optimized out, because it can actually throw an exception depending on the input.

Each approach is equally capable of resulting in an error state if unexpected input is supplied, for example pass an array into the document.getElementById. The largest important difference is that the input to the querySelector must be parsed as a coded instruction, a selector, while the input to getElementById is a string literal that does not get parsed.

Firefox is a terrible browser to use if you want to draw conclusions from microbenchmarks; it's extremely aggressive at eliminating code. In my laptop, `document.getElementById("canvas")` runs at 1b ops/s (roughly the same ops/s as not running any code at all), which should tell you something fishy is going on. For context, in Chrome, I get 200M ops/s for the DOM calls, vs 1b ops/s for doing nothing.

Also worth noting that benchmark.js (the underlying benchmarking library in jsbench) hasn't really aged very well. It doesn't account, for example, for JIT warmup (i.e. if you try to graph time measurements of a payload over time, you should see orders of magnitude changes in numbers between the first few, first few hundreds and fully warmed up calls in a modern js engine.)

So that's your DOM operation... You literally are just accessing the same memory over and over again and because of the super-pipelined nature of CPUs, the fetch itself ends up being pipelined.

It is a sandbox site. You can enter any different custom instructions you wish to see how it performs. If you would like something that is not cached in memory perhaps this instruction isn't:

    document.getElementById("canvas").getElementsByTagName("span")

For me that reduces from 800 million ops/s to about 778 million ops/s

You're not modifying the DOM so obviously those will be fast.

It's the DOM modifications that can easily hang the browser for a noticeable time if the reflow they cause is complex enough.

Then perhaps there is something you aren't doing correctly. It could be your abstraction. Even on old hardware I don't notice this blocking, unless the output is millions of items, when the code is using the native DOM methods.

Here is an application I wrote last year that can output a large table to the DOM pretty quickly even with hundreds of thousands of records: https://sparser.io/demo/

Here is one I am currently working on that can output thousands of file system artifacts to the DOM without any blocking to the user interface. http://mailmarkup.org/sharefile/demo1.mp4

I tried your application and it gets choppy at <80 records on my phone.

It's not "my abstraction" - it's a general problem that many people have been trying to tackle - vDOM is just one of many approaches.

The UI is not developed with a phone in mind, assuming you are talking about the Sparser application. I just attempted this in my IPhone for the first time. Here are the numbers according to the tool (the numbers output to the title box in the top left corner of the screen):

* 108ms raw execution time

* 857ms total browser visual render time

I used this code: https://raw.githubusercontent.com/prettydiff/prettydiff/mast... which generated a table of 23010 records.

The execution performance was better than I expected for a phone and I am not seeing any delay in user interaction. What were your numbers?

I've pasted that snippet and while it did indeed render fast, adding a newline anywhere caused the whole thing to hang for 12 seconds on my phone. Try it - you'll get a similar effect.

It's easy to just render a large page from scratch. Reflowing half of it by e.g. adding some vertical space is what's really hard.

EDIT: Actual numers are lower, but still troubling:

Parsing time: 771.7 milliseconds.

Browser time: 12078.1 milliseconds.

I called you out specifically because you cited "billions of DOM operations per second." Since I work at or near the assembly level often, I found this a bit hard to believe. The query you just sent would also be cached for the same reason. You haven't mutated any state! But at least now I know the initial claim as it stands is complete bogus as suspected and I can move on with my day.