Dev performance reduced by `add_owner_to_object` calls when using a `$state.raw` and a context created by a function

[thes01]

Describe the bug

This issue happens in the development mode only. I believe this bug is somewhat related to #14491, respectively to the fix #14533, which helps with this case for classes, but not functions.

Steps to reproduce:

• set a context that is a POJO with a $state.raw field (e.g. by using a factory function)
• fill the $state.raw with something sufficiently deep
• have multiple child components mount and call getContext to retrieve the context (same symptom as in the referenced PR)

Reproduction

https://svelte.dev/playground/ab1f18a235f44df28eae50837df5bc1d?version=5.19.0

The Svelte REPL apparently cannot build the component in a dev mode, therefore you need to run it in localhost. What I see in the devtool performance monitor is something like this:

Looking at the getContext implementation, it is understandable why this happens. The add_owner_to_object simply recurses into the fields of the state. I hope this could be addressed so that people who don't use classes (for whatever reason) aren't surprised by this.

Logs

System Info

System:
    OS: Windows 11 10.0.26100
    CPU: (16) x64 AMD Ryzen 7 PRO 6850U with Radeon Graphics     
    Memory: 3.64 GB / 14.76 GB
  Binaries:
    Node: 22.9.0 - ~\AppData\Local\fnm_multishells\23524_1737450727692\node.EXE
    Yarn: 1.22.22 - ~\AppData\Local\fnm_multishells\23524_1737450727692\yarn.CMD
    npm: 10.9.0 - ~\AppData\Local\fnm_multishells\23524_1737450727692\npm.CMD
  Browsers:
    Edge: Chromium (131.0.2903.146)
    Internet Explorer: 11.0.26100.1882

Severity

annoyance

[thes01]

We've also seen the add_owner_to_object happen when using useThrelte from Threlte 8. I looked up the implementation and it also uses the factory function pattern, where nothing prevents the deep recursion.

[dummdidumm]

The problem with this is that getContext calls add_owner so that mutations coming from stuff passed through getContext are fine. Since it's $state.raw the algorithm doesn't stop traversal at any point, going through the whole object which is costly - and then it does that for each entry.

Possible solutions:

• do widening at setContext ("everything is allowed for this thing"). Could mean false negatives when you also pass it as a prop that you don't bind but that's likely rare. Could mean worse perf in other places because it's not lazy (theoretically you can never do getContext, but again that's likely also rare)
• do something with WeakMap to save traversed trees that didn't turn up any $state to add ownership to. Results in less runs at the cost of potentialyl higher memory

[thes01]

There's another (I think more serious) side-effect of the current getContext implementation:

If you call getContext in an effect, then all of the states inside are tracked as reads in dev mode and not in production. I guess this would be solved by the first suggestion (moving the ownership thingy to setContext).

Otherwise, I believe the add_owner dev call should be wrapped in untrack.

[jirihon]

Here is a minimal REPL showing the problem with calling getContext inside $effect: https://svelte.dev/playground/bf77ce7c495b45e0955a6901e193c667?version=5.19.3

Incrementing counter_a will trigger the effect that is supposed to run only when counter_b changes.