Update Angular to V18

[krausest]

Update Angular to V18

[pkozlowski-opensource]

I tried to update with ng update, but results didn't look good.

@krausest did the update fail? Or the perf results weren't good? Happy to help, just trying to understand what is going on.

I guess it could be interesting to try the new nozone with the signals one as well

nozone for sure - and those are not tied to signals (I mean, you can run zoneless without using signals).

[birkskyum]

I guess it could be interesting to try the new nozone with the signals one as well

[krausest]

The update itself was fine. For angular-cf-signals I bootstrapped with provideExperimentalZonelessChangeDetection() and added ChangeDetectionStrategy.OnPush to the component.
After that select rows took 87 msecs instead of 6.5 msecs. Swap rows was similarly bad.

[krausest]

If it helps I set up a PR with my changes here: #1695

[krausest]

Those were the results I got. I can remove that image again if you want me to, since I really hope I made a silly mistake (left new keyed, right old keyed results):

[pkozlowski-opensource]

Those were the results I got. I can remove that image again if you want me to, since I really hope I made a silly mistake (left new keyed, right old keyed results):

@krausest thnx for following up on this one. I will have a deeper but I don't see any "silly mistake" looking at the PR. What I do expect that the change detection scheduler we are using might not be playing nicely with the benchmark / way we measure. But yeh, this is just a suspicion for now, will profile!

[pkozlowski-opensource]

@krausest actually I think I know what is going on - at least partly.

For angular-cf-signals I bootstrapped with provideExperimentalZonelessChangeDetection() and added ChangeDetectionStrategy.OnPush to the component.
After that select rows took 87 msecs instead of 6.5 msecs. Swap rows was similarly bad.

Looking at the change in https://github.com/krausest/js-framework-benchmark/pull/1695/files#diff-ede0fde54eaba73652ad146e9d60f72e603ed149428291a7a7fc83c3d667c26aR7 it would make running the change detection at least twice. The reason for this is that we've got now zoneless scheduling change detection and manual calls to detect changes.

[pkozlowski-opensource]

I've removed double calls in a separate commit (see pkozlowski-opensource@307580b) and it significantly improves numbers but still performs worse as compared to the zone-based version.

The interesting thing is that under a profiler I can see select rows performing great so, as noted above, I think that our zoneless scheduler interact in an undesirable way with the benchmarking infrastructure. I didn't get to the bottom of it yet.

So I think we've got 2 issues:

• double calls to change detection (removed in pkozlowski-opensource@307580b)
• new zoneless scheduler and benchmarking

Given this I would suggest the following:

• revert switch to the experimental zoneless (left comments in a PR but can also prepare a patch commit) so we can compare evolution from one version to another;
• work on adding experimental zoneless to be benchmark in a separate PR

WDYT?

[wszgrcy]

May I ask which is the latest modified PR? I would also like to participate and take a look

[krausest]

#1696 contains one new zoneless implementation.
The existing angular implementations were bumped to v18 in 40fc822 (without switching to new zoneless).

[wszgrcy]

Those were the results I got. I can remove that image again if you want me to, since I really hope I made a silly mistake (left new keyed, right old keyed results):

If the test results of different devices have consistent standards
Perhaps this is a performance issue. Need Angular official to resolve it?
Because I feel like there's nothing more to optimize