7 ms·

> DOM operations, in JavaScript, on Firefox already occur at near assembly speed at billions of operations per second Call me skeptical

adev_ 7y ago
> Call me skeptical Yep. I call that FCA/FMA numbers [1]. Only a simple memory allocation is an order of magnitude slower. And I am not even speaking about the cost of boundary crossing between the JS engine and the C++ DOM/render API. [1]: https://www.youtube.com/watch?v=Y21xzVH8NGY https://www.youtube.com/watch?v=Y21xzVH8NGY
austincheney 7y ago
You can see for yourself if you go to https://jsbench.github.io/ https://jsbench.github.io/ Test document.getElementById("canvas"); against document.querySelector("#canvas"); On my really old desktop computer I am running about 800 million operations per second in Firefox 74 on Windows 10. See what numbers you can get up to with modern hardware or a different operating system.
- blattimwind 7y ago
  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.
  - austincheney 7y ago
    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/ https://jsbench.me/
    - blattimwind 7y ago
      > 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.
      - austincheney 7y ago
        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.
- banachtarski 7y ago
  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.
  - austincheney 7y ago
    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
    - Tade0 7y ago
      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.
      - austincheney 7y ago
        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/ 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 http://mailmarkup.org/sharefile/demo1.mp4
        Tade0 7y ago
        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.
- lhorie 7y ago
  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.)

adev_ 7y ago

> Call me skeptical Yep. I call that FCA/FMA numbers [1]. Only a simple memory allocation is an order of magnitude slower. And I am not even speaking about the cost of boundary crossing between the JS engine and the C++ DOM/render API. [1]: https://www.youtube.com/watch?v=Y21xzVH8NGY https://www.youtube.com/watch?v=Y21xzVH8NGY

austincheney 7y ago

You can see for yourself if you go to https://jsbench.github.io/ https://jsbench.github.io/ Test document.getElementById("canvas"); against document.querySelector("#canvas"); On my really old desktop computer I am running about 800 million operations per second in Firefox 74 on Windows 10. See what numbers you can get up to with modern hardware or a different operating system.

blattimwind 7y ago
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.
- austincheney 7y ago
  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/ https://jsbench.me/
  - blattimwind 7y ago
    > 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.
    - austincheney 7y ago
      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.
banachtarski 7y ago
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.
- austincheney 7y ago
  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
  - Tade0 7y ago
    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.
    - austincheney 7y ago
      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/ 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 http://mailmarkup.org/sharefile/demo1.mp4
      - Tade0 7y ago
        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.
lhorie 7y ago
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.)