4 ms·
> 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. t
by 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.