[perf] on-demand vnode reuse

domvm v2 is already fast [1], but i think it can get even faster if people are willing to write their templates a bit differently. this can be done in a backwards-compatible manner by adding an extra signature to the vnode factory functions.

Current signature:

var el = domvm.defineElement,
    vw = domvm.defineView;

function View(vm, data) {
  return () =>
    el("div", [
      el("em", "foo"),
      vw(ItemsView, data.items),
    ])
}

Body-generator signature:

var el = domvm.defineElement,
    vw = domvm.defineView;

function View(vm, data) {
  return () =>
    el("div", d => [
      d.el("em", "foo"),
      d.vw(ItemsView, data.items),
    ])
}

Here’s the idea:

Currently, the new vtree must be generated in full before being returned from render. This means all vnodes must be pre-allocated and after the oldVtree/newVtree diff pass, the old vtree is fully discarded by the GC - which takes time. By returning a body-generating function, we allow things to be lazy and pass in a “donator” d. What d’s methods do is a combination of findDonor and patch, where each vnode is located and re-used on demand from the oldVtree parent. As a result, we shorten the lifetime of any temporary vnodes and let the GC work more efficiently and allocate less stuff.

The syntax difference is small and clean when using ES6, so the templates stay concise (though the compiled ES5 versions would replace d => with function(d) {...} and be beefier).

this is speculation at this point, but i think it may work.

[1] https://rawgit.com/krausest/js-framework-benchmark/master/webdriver-ts/table.html

[leeoniya]

this turned out to be impractical and not worth it. the way in which internal passes are optimized makes implementing this quite ugly and using it quite ugly as well.

if anyone’s unhappy with domvm’s 10% overhead vs vanillajs, they can use another lib…or vanillajs.

[leeoniya]

this will be in v3