4 ms·

I just reran the test page in the repo and browsers have certainly improved. The gains have shrunk to the point (2x speedup at best) that the use of an unsafe A

by oever 9y ago

I just reran the test page in the repo and browsers have certainly improved. The gains have shrunk to the point (2x speedup at best) that the use of an unsafe API would not be recommended for general use. The test can also run a 'Simple' virtual dom which is a naive implementation with Javascript Objects. That one is currently faster than the typed arrays in Firefox, but in Chromium, the typed arrays are still much faster. As a vdom hidden behind an API like in the case of Moon or Vue, typed arrays could still make sense.

leeoniya 9y ago
> The gains have shrunk to the point (2x speedup at best) call me a skeptic, but i suspect that whatever impl you're comparing against is not terribly good. this bench [1] allocates (and discards) ~3,000 virtual nodes per redraw, and each redraw is ~1.3ms, pegged @ 60fps. the GC time is ~2% [2], so even if all GC went away, a 2x speedup is plain impossible. unless you're suggesting that the majority of the time spent in "Scripting" is heap allocations, which i'll concede may be a good amount - do you know if there's a way to measure cumulative time spent growing the heap? [1] http://leeoniya.github.io/domvm/demos/bench/dbmonster/ http://leeoniya.github.io/domvm/demos/bench/dbmonster/ [2] http://imgur.com/a/TwwRf http://imgur.com/a/TwwRf
- oever 9y ago
  > whatever impl you're comparing against is not terribly good. Indeed it is not. The reference is a naive Object based DOM. The benchmark is also not using complete rendering and diffing: it uses versioning on the nodes. It replaces the updated dom nodes at a configurable rendering frequency. So it's very different and probably slower than current frameworks. The remark that triggered the mention of baredom was the supposed unavoidability of the GC. Baredom does not use it and WebAssembly might make non-GC VDoms popular. Still, JS engines GC has gotten very good.

by oever 9y ago

leeoniya 9y ago

> The gains have shrunk to the point (2x speedup at best) call me a skeptic, but i suspect that whatever impl you're comparing against is not terribly good. this bench [1] allocates (and discards) ~3,000 virtual nodes per redraw, and each redraw is ~1.3ms, pegged @ 60fps. the GC time is ~2% [2], so even if all GC went away, a 2x speedup is plain impossible. unless you're suggesting that the majority of the time spent in "Scripting" is heap allocations, which i'll concede may be a good amount - do you know if there's a way to measure cumulative time spent growing the heap? [1] http://leeoniya.github.io/domvm/demos/bench/dbmonster/ http://leeoniya.github.io/domvm/demos/bench/dbmonster/ [2] http://imgur.com/a/TwwRf http://imgur.com/a/TwwRf

oever 9y ago
> whatever impl you're comparing against is not terribly good. Indeed it is not. The reference is a naive Object based DOM. The benchmark is also not using complete rendering and diffing: it uses versioning on the nodes. It replaces the updated dom nodes at a configurable rendering frequency. So it's very different and probably slower than current frameworks. The remark that triggered the mention of baredom was the supposed unavoidability of the GC. Baredom does not use it and WebAssembly might make non-GC VDoms popular. Still, JS engines GC has gotten very good.