Updating from 5.36.10 to 5.36.12 causes everything to become laggy.

[HighFunctioningSociopathSH]

Describe the bug

After updating past svelte@5.36.10 interaction with the page, such as opening or closing a Drawer or dragging it around, which rely on updating a CSS variable and onpointermove event become laggy and the console logs setTimeout or blur violation where their handlers took too long to run and when checking the chunk location they point to a dequeue function. It's worth noting that my experimental flag for the new async stuff is false, and I'm not using it.

Reproduction

Unfortunately, I'm unable to reproduce it in a meaningful way since it is an overall thing, and most interactions seem laggy. There is no release note for the 5.36.11 version, so I'm not sure what happens exactly between svelte@5.36.10 and svelte@5.36.12 But maybe you guys can guess what might be causing the issue.

Logs

System Info

System:
    OS: Windows 11 10.0.26100
    CPU: (16) x64 12th Gen Intel(R) Core(TM) i7-12650H
    Memory: 5.79 GB / 15.63 GB
  Binaries:
    Node: 23.11.0 - C:\nvm4w\nodejs\node.EXE
    npm: 11.4.1 - C:\nvm4w\nodejs\npm.CMD
  Browsers:
    Edge: Chromium (136.0.3240.64)
    Internet Explorer: 11.0.26100.1882

Severity

blocking an upgrade

[dummdidumm]

Most likely #16457, though we still need a reproducible to dig into this. It's ok if it isn't minimal in this case.

[gyzerok]

Wondering if it's worth reverting the PR in the meantime, so upgrading to get other fixes isn't blocked by this?

[Rich-Harris]

We definitely shouldn't revert the PR, since it fixes a number of significant bugs. There are no other fixes between 5.36.10 and 5.36.12 so I would recommend staying on 5.36.10 while we investigate the performance regression

[HighFunctioningSociopathSH]

Great, since I can't reproduce it outside my large project code, I'm going to close this as not planned. I'll open it again if I find it recurring elsewhere, or if I can reproduce it.

[Rich-Harris]

I'd be curious to know if 5.36.14 fixes this

[HighFunctioningSociopathSH]

@Rich-Harris Sorry for the late answer. Unfortunately, I've tested svelte@5.36.14 and even the latest svelte@5.36.17, but the issues still persist. For now, the only version that works fine for me is svelte@5.36.10. I've tried for days to figure out what the issue could be, but I was unsuccessful. Removing dependencies from different deriveds and stopping them from running fixes the issues. Seems like when 2 or more deriveds with similar dependency try to run the $effects, reading these $derived values run into a problem. From my tests, the derived values that seem to be causing the issue run pretty fast, but the $effects that are meant to display the changes halt the main thread. I'll be staying on svelte@5.36.10, but I won't reopen this issue since I still can't reproduce it properly.

[HighFunctioningSociopathSH]

@Rich-Harris After installing Svelte locally and going back and forth between the commits of svelte@5.36.10 and svelte@5.36.12, I can say for sure that my issue is because of the changes that happen to the mark_reactions function. I still don't have any fix for but at least I know it happens because of this commit #16457. Thought I should share this in case it helps.

[Rich-Harris]

Anything you can do to create a repro, however contrived, would help us come up with a solution

[HighFunctioningSociopathSH]

@Rich-Harris, I will try my best with the repro.
But for now, I managed to fix my issue by making the following change =>
Function from svelte@5.36.12

/**
 * @param {Value} signal
 * @param {number} status should be DIRTY or MAYBE_DIRTY
 * @returns {void}
 */
function mark_reactions(signal, status) {
	var reactions = signal.reactions;
	if (reactions === null) return;

	var runes = is_runes();
	var length = reactions.length;

	for (var i = 0; i < length; i++) {
		var reaction = reactions[i];
		var flags = reaction.f;

		// In legacy mode, skip the current effect to prevent infinite loops
		if (!runes && reaction === active_effect) continue;

		// Inspect effects need to run immediately, so that the stack trace makes sense
		if (DEV && (flags & INSPECT_EFFECT) !== 0) {
			inspect_effects.add(reaction);
			continue;
		}

		// don't set a DIRTY reaction to MAYBE_DIRTY
		if ((flags & DIRTY) === 0) {
			set_signal_status(reaction, status);
		}

		if ((flags & DERIVED) !== 0) {
			mark_reactions(/** @type {Derived} */ (reaction), MAYBE_DIRTY);
		} else if ((flags & DIRTY) === 0) {
			schedule_effect(/** @type {Effect} */ (reaction));
		}
	}
}

Function with my changes =>

/**
 * @param {Value} signal
 * @param {number} status should be DIRTY or MAYBE_DIRTY
 * @returns {void}
 */
function mark_reactions(signal, status) {
	var reactions = signal.reactions;
	if (reactions === null) return;

	var runes = is_runes();
	var length = reactions.length;

	for (var i = 0; i < length; i++) {
		var reaction = reactions[i];
		var flags = reaction.f;

		// In legacy mode, skip the current effect to prevent infinite loops
		if (!runes && reaction === active_effect) continue;

		// Inspect effects need to run immediately, so that the stack trace makes sense
		if (DEV && (flags & INSPECT_EFFECT) !== 0) {
			inspect_effects.add(reaction);
			continue;
		}

		// don't set a DIRTY reaction to MAYBE_DIRTY
		if ((flags & DIRTY) === 0) {
			set_signal_status(reaction, status);
		}

		if ((flags & DERIVED) !== 0) {
			// Optimization: only recurse if CLEAN or UNOWNED
			if ((flags & (CLEAN | UNOWNED)) !== 0) {
				mark_reactions(/** @type {Derived} */ (reaction), MAYBE_DIRTY);
			}
		} else if ((flags & DIRTY) === 0) {
			schedule_effect(/** @type {Effect} */ (reaction));
		}
	}
}

Essentially, it brings back the following safeguard

			// Optimization: only recurse if CLEAN or UNOWNED
			if ((flags & (CLEAN | UNOWNED)) !== 0) {
				mark_reactions(/** @type {Derived} */ (reaction), MAYBE_DIRTY);
			}

I'm sure you had your reasons to remove it, but putting it back fixes my performance issue.
From the commit message:

if a derived is read inside a time-travelling batch, it isn't (and can't) be marked clean afterwards

That means the derived’s CLEAN flag might be lying

Maybe something like

const in_time_travel = is_time_travel_batch(); // hypothetical check

if ((flags & DERIVED) !== 0) {
	// only recurse if clean/unowned *or* if we're not in a special batch mode
	if (!in_time_travel && (flags & (CLEAN | UNOWNED)) === 0) continue;
	mark_reactions(/** @type {Derived} */ (reaction), MAYBE_DIRTY);
}

or

if ((flags & DERIVED) !== 0) {
	// only recurse if clean/unowned *or* if we're not in a special batch mode
	if ((flags & (CLEAN | UNOWNED | TIME_TRAVELING)) === 0) continue;
	mark_reactions(/** @type {Derived} */ (reaction), MAYBE_DIRTY);
}

Could be a middle ground?