chore: tweak hydration implementation

[Rich-Harris]

We create an array of nodes when hydration, and attach it to effects as the dom property. In non-hydration mode, we turn a DocumentFragment into an array of nodes.

This all creates extra work and allocates extra memory. I was curious as to whether we could speed up hydration by just storing the 'bookends', taking advantage of the fact that the DOM is basically a bunch of linked lists. In this PR there's no more hydrate_nodes, just hydrate_start and hydrate_end, and effect.dom has been replaced by effect.d1 and effect.d2.

It seems to be faster in some cases but not all (perhaps because I'm prepending fragments with an empty text node so that effect.d1 isn't shared between multiple effects, which makes life rather complicated). More investigation needed. I do think the code is a little nicer this way, so I'm hopeful that it can be made faster in all cases.

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: 04415e9

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]

Digging into this PR, it seems we are doing more node.nextSibling calls more compared to before, which seems to have the biggest cost. I wonder if #11694 will help here.

[Rich-Harris]

Man, I'm totally flummoxed by this. Firstly, the tests pass locally, I have no idea why they don't in CI.

Secondly, this is slower than main even though it's doing less work. Insanely, if I make this change...

diff --git a/packages/svelte/src/internal/client/dom/hydration.js b/packages/svelte/src/internal/client/dom/hydration.js
index d51ae78ca..1a7c1bedb 100644
--- a/packages/svelte/src/internal/client/dom/hydration.js
+++ b/packages/svelte/src/internal/client/dom/hydration.js
@@ -40,6 +40,7 @@ export function hydrate_anchor(node) {
 		/** @type {Comment} */ (node).nextSibling
 	);
 
+	var nodes = [];
 	var current = hydrate_start;
 	var depth = 0;
 
@@ -51,6 +52,7 @@ export function hydrate_anchor(node) {
 				depth += 1;
 			} else if (data[0] === HYDRATION_END) {
 				if (depth === 0) {
+					hydrate_start = nodes[0];
 					return current;
 				}
 
@@ -58,6 +60,7 @@ export function hydrate_anchor(node) {
 			}
 		}
 
+		nodes.push(current);
 		current = /** @type {import('#client').TemplateNode} */ (current.nextSibling);
 	}

...it speeds up again. This offends reason.

[trueadm]

Man, I'm totally flummoxed by this. Firstly, the tests pass locally, I have no idea why they don't in CI.

Secondly, this is slower than main even though it's doing less work. Insanely, if I make this change...

diff --git a/packages/svelte/src/internal/client/dom/hydration.js b/packages/svelte/src/internal/client/dom/hydration.js
index d51ae78ca..1a7c1bedb 100644
--- a/packages/svelte/src/internal/client/dom/hydration.js
+++ b/packages/svelte/src/internal/client/dom/hydration.js
@@ -40,6 +40,7 @@ export function hydrate_anchor(node) {
 		/** @type {Comment} */ (node).nextSibling
 	);
 
+	var nodes = [];
 	var current = hydrate_start;
 	var depth = 0;
 
@@ -51,6 +52,7 @@ export function hydrate_anchor(node) {
 				depth += 1;
 			} else if (data[0] === HYDRATION_END) {
 				if (depth === 0) {
+					hydrate_start = nodes[0];
 					return current;
 				}
 
@@ -58,6 +60,7 @@ export function hydrate_anchor(node) {
 			}
 		}
 
+		nodes.push(current);
 		current = /** @type {import('#client').TemplateNode} */ (current.nextSibling);
 	}

...it speeds up again. This offends reason.

Dare I say it, do we just do this to get this PR landed? Obviously with comments explaining why. We can then at least compare this to the other PR of yours and see where we go with that.

Also it seems your recent tweaks caused the tests to fail?

[Rich-Harris]

Merged #12215 so will close this