Generation of $.template_effect() - trade-off between code size and run-time re-render effort?

[ptandler]

After Simon gave this wonderful presentation this week (thanks again @dummdidumm), I had some time now to look into the nice Svelte 5 playground and created a very simple App that uses a Counter component:

Looking at the generated JS code of Counter.svelte, I noticed the compiler generates a single $.template_effect() containing updates for all reactive blocks in the template:

	$.template_effect(() => {
		$.set_text(text, `${$.stringify(name())} `);
		$.set_text(text_1, `clicks: ${$.stringify($.get(count))}`);
	});

In this example, replacing text should be pretty quick to execute, so it might not matter. However, I wonder if it would be more efficient for more complex examples, with a lot more reactive blocks or time consuming computation, to generate a separate $.template_effect() for each element that could be changed, e.g.

	$.template_effect(() => {
		$.set_text(text, `${$.stringify(name())} `);
	});
	$.template_effect(() => {
		$.set_text(text_1, `clicks: ${$.stringify($.get(count))}`);
	});

I haven't looked into the details of the implementation, but I expect that doing it this way would minimize updating only the parts of the UI that really did change? E.g. when the name changes, only this effect is executed, the counter part is unchanged and not computed again.

I guess you have reasons why you decided to generate a single effect? Is it to reduce code size as the runtime effect does not matter much?

In general, it's my experience that it's a good idea to reduce the number of dependencies of effect / derived / computed signals as much as possible as it happens surprisingly often that you get unwanted and unnecessary re-computation resulting in inefficient code.

[dummdidumm]

First of all thank you for the kind words 😊

We benchmarked this and found that it's actually more performant to have less render effects. Reasoning: each render effect has a non trivial tax on performance. Identifiers cannot have side effects so it's safe to group them. Member expressions could but should not (and in praxis almost never have), i.e. it's safe to group them, too. Note that we're still doing a diff after getting the new value so we don't actually update the Dom if nothing changed. And call expressions get their own isolated render effect because it's more likely to contain side effects / non trivial computations.

[ptandler]

Ah, thanks for your quick reply and the explanation! I actually never thought about the performance implications of the number of effects. Is this the number of effects per component or in total? When I've got some time (...) I'll look at the implementation.

Having an expression with side effects inside a reactive blocks or derived signal is really not a good idea, that's true.

[dummdidumm]

The total number of effects - each one has a non diminishable amount of overhead, and so having fewer is better if the things they're listening to are quick enough to recompute or compare.