4 ms·

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 fetc

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.
      - austincheney 7y ago
        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/master/beautify/script.ts 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?
        Tade0 7y ago
        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.
- banachtarski 7y ago
  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.

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.
    - austincheney 7y ago
      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/master/beautify/script.ts 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?
      - Tade0 7y ago
        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.
banachtarski 7y ago
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.