⚡ Improves x-for performance

[ekwoka]

This also solves #4192 #4157 related to using x-sort with x-for.

The core issue is that x-for never checks if any elements have moved, due to how it is optimized.

See in playground

I looked at just solving that directly, but it would definitely just increase work and increase code.

I identified that, if we want to just always ensure we put the elements in the right place, then we could also massively simplify the logic while maintaining the vast majority of the logic and optimizations, and solve this problem.

Looks like my test for the x-sort issue is missing so I'll get that in place.

Note: As I worked through this, I was quite impressed with how optimized Alpine actually was in the first place. It wasn't a joke when you said it was complexity with a purpose. I was quite worried I'd end up in a situation where the code logic was uglier, longer, slower, and there were times when the old version was doing way better at things I wasn't sure how to handle effectively. Had to do a lot of profiling to find the simplest fixes. Wrote a blog post about the steps, process, logic.

I think I got there. Smaller, faster, and I think many would agree clearer logic.

Synthetic Benchmarks

Some synthetic benchmarks that isolated just the x-for logic. This number includes the browser repaint/reflow, not purely logical gains. For most, the repaint/reflow is the same/similar for both.

Action	Refactored	Diff from Original
Add 10,000 Items	124.235	-20 (-14%)
Add Additional 1 Item	32.845	-27 (-45%)
Shuffle 10,001 Items	165.770	-68 (-29%)
Remove 1 Item	54.895	-5 (-8%)
Swapping 2 Items	61.250	14 (30%)
Sort 10,000 Items	142.555	-71 (-33%)
Reverse 10,000 Items	146.460	-306 (-68%)
Remove Every Other Item	42.130	-9 (-17%)
Remove Remaining 5,000 Items	16.530	-7 (-31%)

JS Framework Benchmarks

Name	With Refactor	Before Refactor
create rows	140.1	144.3
replace all rows	154.5	165.6
updating every 10th row	29.5	29.9
select row	51.5	56.4
swap rows	42.1	45.1
remove row	32.1	33.7
create many rows	1,169.8	1,236.7
append rows to large table	146.4	157.7
clear rows	69.1	62.9
weighted mean	2.45	2.54

Extra Huge Lists

For fun.

Action	Original	Refactor	Difference (%)
Adding 10,000 + 10,000 Items	258	157	-39.15%
Add 100,000 Items	2,784	1,491	-46.44%
Rerender Same Items	2,863	125	-95.63%
Shuffling 100,000 Items	8,163	1,839	-77.47%
Removing Every Other Item	1,855	338	-81.78%
Removing 100,000 Items	827	115	-86.09%

[browner12]

while I don't necessarily disagree with some of the formatting changes in here, wouldn't it be best to remove them for now to make the PR easier to review?

[ekwoka]

Sure. I think there's like 2 or 3 that just got caught up in the mix. They're quite separate from the main code so it shouldn't be too much noise though. When I get the test in, I can correct some of those.

[jackvanderbilt-visma]

Using Object.keys and then doing items[key] is more verbose but may be faster and more memory efficient, though I am not sure.

Also the forEach could be replaced with a standard for loop which is faster too.

[ekwoka]

For loops are generally not faster than array methods in modern JS runtimes. The engine can more efficiently loop than doing it in your own code. Since the method doesn't need to be concerned about breaks and continues and returns and such. It's quite interesting getting into the meat of that, but mostly the array methods are just clearer logically.

Though really this should probably be a map for maximum efficiency 🤔

The Object.keys is to make it work with Arrays and Objects with a single code path.

Could maybe be handled in a different way, like just separately replacing items when it's an object with an array of entries.

I need to get that test made and other tweaks.