Should browsers do bookkeeping on DOM parts after initial parse?

[iteriani]

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.

[rniwa]

What kind of bookkeepings are there?

[iteriani]

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.

[rniwa]

Why is supporting getParts() to be updated so expensive? It seems like an implementation problem to me.

[iteriani]

We’re going to look into seeing if we’re doing anything egregious. I guess if we’re using ChildNodePart.replaceChildren with a document fragment, the operation to update parts should be pretty cheap. I was thinking with a normal dom element, you’d have to track its owner part and move the related parts accordingly, but we’re not exactly doing that.

…

On Fri, Sep 15, 2023 at 12:49 PM Ryosuke Niwa ***@***.***> wrote: Why is supporting getParts() to be updated so expensive? It seems like an implementation problem to me. — Reply to this email directly, view it on GitHub <#1030 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA2MCG4HSHW2E25UIAWDYWDX2QXEHANCNFSM6AAAAAA4ZR4NWQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[mfreed7]

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.

[justinfagnani]

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.

[iteriani]

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

[mfreed7]

can definitely be investigated further

…is actively being investigated further…