Optimization: Split template_effects up based on what signals they reference #14983
Description
Describe the problem
Minor, but if you were to have many different reactive interpolations in the template, like this...
<h1>Here's one: {thing}</h1>
<h2>Here's another one: {otherThing}</h1>
<h3>Here's a third one: {otherOtherThing}</h3>
<!-- and so on... -->These would all go in the same template effect in compilation. This could lead to unnecessary DOM operations (all interpolations update when any dependency changes, even if only one operation in the effect relies on that dependency) and could soon lead to "death by a thousand cuts" with performance issues, as the component grows in size and complexity. As more and more large applications get built in Svelte, it seems crucial to minimize unnecessary operations.
Describe the proposed solution
It would be nice if Svelte's compiler could split up template effects based on their perceived dependencies, if the number of operations/dependencies used reaches a certain threshold. This would not be like Svelte 4, where reactivity is driven by the compiler, as this would still use template effects, but this would look at the dependencies directly used in each template effect operation, and group them by their perceived dependencies. If these groupings lead to $.template_effects with a relatively small number of operations, the smallest $.template_effects could be grouped together into one effect.
Here's an example:
// insert component boilerplate here...
let state1 = $.state(1);
let state2 = $.state(2);
let state3 = $.state(3);
// insert code here...
$.template_effect(()=>{
// somewhat large number of operations that the compiler can tell use `state1` here...
});
$.template_effect(()=>{
// somewhat large number of operations that the compiler can tell use `state2` here...
})
$.template_effect(()=>{
// somewhat large number of operations that the compiler can tell use `state3` here...
})Importance
nice to have