Open nolanlawson opened 1 year ago
This issue has been linked to a new work item: W-13814092
If you look at the js-framework-benchmark
, the VDOM frameworks that are faster than us in the "select row" test are all relying on a shouldComponentUpdate
/memo strategy:
E.g. Vue:
v-memo="[label, id === selected]"
We can do this, but it feels a bit unsatisfying to me, since it requires manual work on the part of the component author. It would be neat if we could do this automatically instead.
I was looking at how Solid does it, and they have something similar to our static fragment approach. They create a fragment like this:
_tmpl$3 = /*#__PURE__*/template(`<tr><td class="col-md-1"></td><td class="col-md-4"><a> </a></td><td class="col-md-1"><a><span class="glyphicon glyphicon-remove" aria-hidden="true"></span></a></td><td class="col-md-6">`);
... then they do surgical reactive updates on the part that changes (the text node content):
children: row => {
let rowId = row.id;
return (() => {
const _el$11 = _tmpl$3(),
_el$12 = _el$11.firstChild,
_el$13 = _el$12.nextSibling,
_el$14 = _el$13.firstChild,
_el$15 = _el$14.firstChild, // textnode
_el$16 = _el$13.nextSibling,
_el$17 = _el$16.firstChild;
_el$12.textContent = rowId;
_el$14.$$click = setSelected;
_el$14.$$clickData = rowId;
_el$17.$$click = remove;
_el$17.$$clickData = rowId;
createRenderEffect(_p$ => {
const _v$ = isSelected(rowId) ? "danger" : "",
_v$2 = row.label();
_v$ !== _p$._v$ && className(_el$11, _p$._v$ = _v$);
_v$2 !== _p$._v$2 && (_el$15.data = _p$._v$2 = _v$2); // textnode data updated here
return _p$;
}, {
_v$: undefined,
_v$2: undefined
});
return _el$11;
})();
(Note they do firstChild
/nextSibling
because browsers use linked lists under the hood, so this is faster than allocating a children
array.)
This is very similar to our static fragment optimization, except that we don't do it for anything that changes dynamically.
So here's what we could do:
ReactiveObserver
that captures the value of cmp.foo
.cmp.foo
changes, update the text node content.The magic part is step 3 – if we enclose over the cmp.foo
getter (i.e. replace the currentReactiveObserver
), then it will not trigger the template's ReactiveObserver
, so we won't re-run the tmpl
function at all. (Unless cmp.foo
is used somewhere else – then we will have to recreate the whole VNode array from scratch.)
We can gradually introduce this optimization. E.g. we can start with text nodes, then move on to classes, then attributes, etc. We might also start with shallow subtrees to avoid the firstChild
/nextSibling
dance (similar to what we currently do for static vnodes with events/refs).
After internal discussion: another intermediate step we can take is to do the "static-ish fragment" optimization before the fine-grained reactivity optimization. Presumably the cloneNode()
optimization alone would get us some perf wins.
A potential game plan:
lwc:ref
work. Putting the machinery in place to do the firstChild
/nextSibling
dance should lay the groundwork for the next phasecloneNode(true)
.😐 => my face because I can't comprehend most of what you commented above.
@nolanlawson Which docs/books can I read to learn the fundamentals to understand what you said above?
@AllanOricil This is a pretty dense topic, but if you watch some streams from Ryan Carniato or his blog posts you can find some information on this. In particular, the ones where he talks about js-framework-benchmark should be helpful. Sorry I can't provide any more detail than that!
That is a start. Thank you
Update: tracking progress on this as separate issues/PRs:
class
/style
)style
class
createRenderEffect
ala SolidJS)In the
js-framework-benchmark
, our slowest area is currently "select row":The main thing about this test is that it's rendering 10k rows and then only updating every 10th one. So we are generating 9k VDOM nodes that never change and then uselessly diffing them.
The static content optimization helps a bit (https://github.com/krausest/js-framework-benchmark/pull/1288), but it's not perfect because we still have the
key
which is different for every row, so not every VDOM can be static-optimized.I can think of a few ways to optimize this:
v-memo
; this is how they're able to get a high score on this benchmark.key
outside of the vdom inside of the loop somehow – this would allow the underlying vdom to be more likely to be statically-optimized. (It would help with this benchmark, but maybe not with more dynamic iterator content.) We could also make this part of building a replacement iterator directive likelwc:each
(https://github.com/salesforce/lwc/issues/3303).