3 ms·

These benchmarks are tough to reproduce (for all libs). Mithril's instructions say, "To run an execution time test on this page, run the profiler from your brow

These benchmarks are tough to reproduce (for all libs). Mithril's instructions say, "To run an execution time test on this page, run the profiler from your browser's developer tools and measure the running time of a page refresh. (Lower is better)" There are a lot of variables that affect a full page refresh...caching, etc. I could not get those ms numbers in any scenario, not sure what I should be looking at. Would be more useful to stress-test the lib by implementing dbmonster [1] and speedtest* [2]. These perf tests have the benefit of being good visual comparisons and also stressing the browser's GC to evaluate how efficient a lib is at minimizing overall mem usage and reducing jank. I've been working on a DOM view layer lib [3] that does exceptionally well in both of those. (more demos and docs coming soon). EDIT: added domvm dbmonster demo [4] *speedtest is ultra-slow in FF for all libs, the winner is surprisingly innerHTML. still need to narrow down the cause to open an FF bug. [1] http://joelrich.github.io/fastest-dbmonster/ http://joelrich.github.io/fastest-dbmonster/ [2] http://rawgit.com/crysalead-js/dom-layer/master/examples/speedtest/speedtest.html http://rawgit.com/crysalead-js/dom-layer/master/examples/spe... [3] https://github.com/leeoniya/domvm https://github.com/leeoniya/domvm [4] http://leeoniya.github.io/domvm/test/bench/dbmonster/ http://leeoniya.github.io/domvm/test/bench/dbmonster/

daliwali 11y ago
I agree that it would be more informative to stress-test using a more real-world use case, I was just in a hurry and used the render benchmark from Mithril.js. however I think that any benchmark may be skewed to favor a particular implementation. for example, Simulacra.js doesn't batch updates and render asynchronously, it's purely synchronous, so one could set up an artificial benchmark to thrash the DOM by setting different values over and over again in the same tick. also I haven't yet committed the benchmark I used in git, will do later so that people can reproduce it.
- leeoniya 11y ago
  this is correct, and Mithril's docs also point this out. domvm uses rAF internally to debounce changes but it can be toggled off (and IS toggled off [1]) for perf tests to make it 100% synchronous as well (via domvm.useRaf = false). would be very interested to see Simulacra's perf in those, when ready. thanks! [1] https://github.com/leeoniya/domvm/blob/master/test/bench/dbmonster/index.html#L21 https://github.com/leeoniya/domvm/blob/master/test/bench/dbm...
  - daliwali 11y ago
    I added a benchmark folder: https://github.com/0x8890/simulacra/tree/master/benchmark https://github.com/0x8890/simulacra/tree/master/benchmark cheers!

daliwali 11y ago

I agree that it would be more informative to stress-test using a more real-world use case, I was just in a hurry and used the render benchmark from Mithril.js. however I think that any benchmark may be skewed to favor a particular implementation. for example, Simulacra.js doesn't batch updates and render asynchronously, it's purely synchronous, so one could set up an artificial benchmark to thrash the DOM by setting different values over and over again in the same tick. also I haven't yet committed the benchmark I used in git, will do later so that people can reproduce it.

leeoniya 11y ago
this is correct, and Mithril's docs also point this out. domvm uses rAF internally to debounce changes but it can be toggled off (and IS toggled off [1]) for perf tests to make it 100% synchronous as well (via domvm.useRaf = false). would be very interested to see Simulacra's perf in those, when ready. thanks! [1] https://github.com/leeoniya/domvm/blob/master/test/bench/dbmonster/index.html#L21 https://github.com/leeoniya/domvm/blob/master/test/bench/dbm...
- daliwali 11y ago
  I added a benchmark folder: https://github.com/0x8890/simulacra/tree/master/benchmark https://github.com/0x8890/simulacra/tree/master/benchmark cheers!