⚡ 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 behavior and optimizations, while solving this initial problem.

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.

[craigballinger]

Thanks for all your work on this! Any estimate when it might be merged in?

[simonkincaidkintronix]

I think this will fix a problem that has stumped me for a good few hours now. Just bumping to see if we can merge it in?

[Senitram666]

I think this will fix a problem that has stumped me for a good few hours now. Just bumping to see if we can merge it in?

you can use this to test and check about your specific issue, while we wait for the merge

#4383 (reply in thread)

[brianfeister]

Also, btw really great work @ekwoka in terms of being so thorough with the benchmarking. 🏆

Agreed that for loops as an optimization aren't generally relevant in modern JS runtimes

[brianfeister]

LGTM

[brianfeister]

I'm getting hit pretty hard by this bug.

@calebporzio can you or someone on the core team review / merge this? The sortable problem described here is a really tragic oversight in terms of merging that plugin without x-for support. Also discussed here with super basic x-sort implementation bug: #4192