chore: single-pass hydration

[Rich-Harris]

More hydration experimentation. I'm not going to take this any further for now as I have other things to do, but I'll leave it here to pick up at some point in the future.

The main finding from #11690 is that nextSibling is the most expensive part of hydration. It stands to reason, therefore, that we could speed things up by doing it less often. Currently, we do two passes — one in hydrate_anchor, and one in each effect body (where we call functions like first_child and child and — crucially — sibling). If we could avoid calling hydrate_anchor at all, it should therefore have a significant impact on hydration speed.

I have no idea if this is actually possible, but I'm experimenting with it. At the very least, it seems wholly unnecessary to enclose <svelte:element> and CSS custom property wrapper divs in hydration markers — in the first case we do need an anchor (to handle the this={falsy} case) but in the latter we don't need anything at all. For now we still call hydrate_anchor with the element in question, but this exits early rather than traversing. I hope we can extend this approach to other cases — ideally we would only need to do an eager pass for things like mismatched if/each blocks.

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.

Tests and linting

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

[changeset-bot]

⚠️ No Changeset found

Latest commit: 3296520

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

[trueadm]

I fear that this will mean we won't capture hydration issues as well. However, it seems possible to do in practice and I'd love to see how this performs comparatively to what we have on main and your other PR. Given the amount of failing tests though, it does worry me that we'll need to add lots of extra logic for edge cases. It's a real shame we can't use elements with display: contents and thus avoid hydration markers altogether.

[Rich-Harris]

merged #12335, closing