hydration takes way too long

[HighFunctioningSociopathSH]

Describe the bug

I noticed my codebase's hmr not working as fast as before so after checking previous versions to see whether I'm hallucinating or not, I figured out that for some reason from version 5.17.5 forward the hmr takes 3 or more seconds, depending on how many instances of a component where rendered, to kick in. The delay duration goes up for each components instance that is rendered. Unfortunately I was unable to find the exact reason why this is happening; Taking away props passed to components reduces the delay of hmr But I don't think its any single prop that is responsible.

Reproduction

Since I can't reproduce it properly and the issue seems to become noticeable when there are a number of components being rendered, I was wondering If any knowledgeable individual can explain what the 5.17.5 patch actually does and what could be causing this issue. The exact same codebase works fine if I move back to 5.17.4 patch and hmr becomes instant. I was also wondering If anyone else is experiencing the same issue.

Logs

System Info

System:
    OS: Windows 11 10.0.22631
    CPU: (16) x64 12th Gen Intel(R) Core(TM) i7-12650H
    Memory: 7.97 GB / 15.63 GB
  Binaries:
    Node: 23.7.0 - C:\Program Files\nodejs\node.EXE
    npm: 11.1.0 - C:\Program Files\nodejs\npm.CMD
    bun: 1.1.3 - ~\.bun\bin\bun.EXE
  Browsers:
    Edge: Chromium (129.0.2792.52)
    Internet Explorer: 11.0.22621.3527

Severity

blocking an upgrade

[HighFunctioningSociopathSH]

I tried setting hmr to false in compilerOptions and the issue still persists, Apparently its on each re-render and not hmr's fault.

[HighFunctioningSociopathSH]

chrome's devtools says its a microtask called _hydrate that is taking incredibly long so its the hydration process. unfortunately until this hydration microtask finishes, everything is frozen. Now the question is, what did version 5.17.5 do to make this _hydrate function take so much longer to run?

[HighFunctioningSociopathSH]

So If I render 15 instances of my component, I get the following result:

[HighFunctioningSociopathSH]

Maybe @trueadm knows something since he worked on 5.17.5 version?

[trueadm]

Are you saying the performance issue came in 5.17.5? Are you sure it's this exact version, as pinpointing it would be helpful here.

[HighFunctioningSociopathSH]

The performance issue came in 5.17.5 and is present afterwards. I'm sure 5.17.4 is fine because if I install it the issue goes away and hydration becomes instant. As of 5.19.10 the issue is still present.

[trueadm]

Looking at the release, there's nothing related to hydration https://github.com/sveltejs/svelte/releases/tag/svelte%405.17.5. So I'm stumped as to what could be causing it without being able to see a full profile. Can you export the Chrome performance profile please?

[dummdidumm]

Guessing it's #14989 because a loop was introduced there, so it seems something is causing that to run many times? But yeah, a reproduction is crucial or else we're just guessing and can't fix.

[trueadm]

The above shows _hydrate having a huge self-time though. @HighFunctioningSociopathSH are you using web components?

[trueadm]

I found two cases that we can skip doing the work for in that PR, but without a reproduction it's hard to know what more we can do #15275.

[HighFunctioningSociopathSH]

@trueadm I'm not using any web components.

The output from chrome's devtools is a big json and I can't upload it here. This time I only rendered 5 instances of the component that is causing the issue. So here is a link to it
5.17.5 => Json file.
I'm not sure how, But I hope it can be useful.
For comparison this is the performance output from version 5.17.4 thats works fine.
5.17.4 => Json file

[trueadm]

Yep the culprit is schedule_possible_effect_self_invalidation. Which seems to because it's inside a flushSync from the introstart event. How are you listening to this event?

[trueadm]

@HighFunctioningSociopathSH Can you try the latest release please?

[HighFunctioningSociopathSH]

@trueadm I'm sorry for the delayed respond but thankfully the issue is fixed in the latest release. Great work.

[HighFunctioningSociopathSH]

@trueadm Hello again, It seems like a similar issue has risen again after updating to [email protected] version. Everything works fine on [email protected] but after upgrading to [email protected] and as of version [email protected] hydration takes a few seconds.
Just like before I'm going to send links to 2 different trace logs in hope that they will help:
[email protected] => https://drive.google.com/file/d/1VDm94fvBINbKXWbsHgPtZgW5dV-asJqY/view?usp=sharing

[email protected] => https://drive.google.com/file/d/1ex4B0FCxaa1t8u8-Eq23KsdVCcjn_6TI/view?usp=sharing

[dummdidumm]

At this point we really need a minimum reproducible

[HighFunctioningSociopathSH]

@dummdidumm I understand. I'll try my best but I'm stumped just like you guys. Can't seem to reproduce it in simple and concise way.

[HighFunctioningSociopathSH]

@dummdidumm Just a question, here you said

From a quick glance reaction cannot be falsy at this position, therefore "not null" is included in that comparison

But as @trueadm mentioned, the check for null was for "previous_reaction", not "reaction", that means unlike the previous version that made sure "previous_reaction" was not null, here the code only makes sure "previous_reaction" and "reaction" are not the same and there is a possiblity that "previous_reaction" goes through as null. could that be the culprit here?

[dummdidumm]

goddammit, yes this is the culprit - my suggestion on that PR was just wrong, opened another PR with a fix.