Should browsers do bookkeeping on DOM parts after initial parse?
iteriani opened this issue · comments
See preliminary benchmark in https://playcode.io/1595899 using chrome-dev with experimental platform features on.
My numbers appear to be
cloning
8.100000023841858
getParts
1.5000000447034836
accessNodes
1.0999999791383743
operations
1.800000011920929
replaceChildren
30.5
As you can see, there is huge overhead in replaceChildren, presumably to do bookkeeping on keeping the parts up to date. Given how we expect users to use DOM parts in frameworks, we should think about whether bookkeeping is necesary in v1.
What kind of bookkeepings are there?
Consider the following test case.
const el = template`<div>{{#}}{{/#}}</div>`;
const child = template`<span>{{#}}Something here{{/#}}</span>`;
const part = el.content.getPartRoot().getParts()[0];
expect(part.getParts().length).toBe(0);
part.replaceChildren(child);
expect(part.getParts().length).toBe(1);
I personally would be ok with the last assertion to be 0.
Why is supporting getParts() to be updated so expensive? It seems like an implementation problem to me.
Why is supporting getParts() to be updated so expensive? It seems like an implementation problem to me.
I tend to agree - I’d refrain from making API decisions too early based on the early prototype. I haven’t had much time to optimize and it’s likely there’s something easy that could be fixed in replaceChildren.
That said, it’d be good to have the debate about whether tracking is necessary, because it certainly has non-zero overhead. Removing it will make the basic operations faster. But I don’t know if removing it will make the usage of the API faster, since it might require more work to be done on the framework side.
If bookkeeping does end up being irreducibly expensive, I was definitely partial to the template.cloneWithParts() API before, which essentially required any bookkeeping to be done on the JS side. If you don't have uncontrolled DOM mutations, where you then have to ask for the current parts, this seems fine.
Mason fixed up my benchmark a little bit, so now we're a little bit better with DOM parts being about 1.3x slower (can definitely be investigated further).
See https://playcode.io/1595899
can definitely be investigated further
…is actively being investigated further…