wip: store additional property in WeakMap instead of on the event object directly.

[laszlokorte]

Another approach to fix #16522

Instead adding a __root property to the event object itself a WeakMap is used to associate the event with the propagation meta data.

Before submitting the PR, please make sure you do the following

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• Prefix your PR title with feat:, fix:, chore:, or docs:.
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.
• If this PR changes code within packages/svelte/src, add a changeset (npx changeset).

Tests and linting

• Run the tests with pnpm test and lint the project with pnpm lint

[changeset-bot]

⚠️ No Changeset found

Latest commit: 57969ed

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[dummdidumm]

Pretty sure this will erase most perf and memory advantages of event delegation. Is there really no other way?

[github-actions]

Playground

pnpm add https://pkg.pr.new/svelte@16532

[laszlokorte]

Why do you think that the WeakMap has worse performance than adding a propety to the event?
Are there existing benchmarks in svelte to measure this?

[laszlokorte]

I filed a bug report for Firefox:
https://bugzilla.mozilla.org/show_bug.cgi?id=1980416

[Rich-Harris]

Why do you think that the WeakMap has worse performance

It's a fair question, since modifying the shape of an object also has performance implications. Personally I'm just used to treating WeakMap as a last resort because it's known to be somewhat slow, though I don't have any data ready to hand.

In the past @trueadm has referenced js-framework-benchmark a lot, and we could try this PR and an alternative one I just created — #16538 — to see if there's any difference. I remember the benchmark being an absolute nightmare to set up though

[Ocean-OS]

Wouldn't the perf implications be practically nonexistent due to hidden classes?

[Rich-Harris]

Honestly I dunno, outside my area of expertise

[Rich-Harris]

Since #16538 was merged I'll go ahead and close this but am open to an alternative solution if the benchmarks indicate it. Thank you

[trueadm]

Wouldn't the perf implications be practically nonexistent due to hidden classes?

There's a difference between deopting an object vs just using a computationally expensive data structure. If you consistently de-opt and object, the VM will bail out trying to make it monomorphic. That's not ideal, but completely acceptable and happens all the time in JS land. WeakMaps are just very expensive computationally due to their need to handle weak references and the burden it has on the GC and the JIT compiler.