Implement index tracking to optimize list operations#8519
Open
UnderscoreTud wants to merge 6 commits intodev/patchfrom
Open
Implement index tracking to optimize list operations#8519UnderscoreTud wants to merge 6 commits intodev/patchfrom
UnderscoreTud wants to merge 6 commits intodev/patchfrom
Conversation
sovdeeth
approved these changes
Apr 3, 2026
APickledWalrus
approved these changes
Apr 9, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
When adding an element to a list, Skript scans through the entire list to find an open spot for the element. This is a pretty slow operation with a time complexity of O(n), and adds up extremely fast, to the point where adding 10k elements to a list takes around 11 seconds on my machine.
Deleting a list using
delete {_list::*}loops through every index and removes it individually. This is done to ensure all sublists are also deleted, but this is also done even if the list doesn't have any sublists!.Also for some reason the logic for deleting a list is effectively this:
So, deleting a list actually deletes it twice
Solution
Adding
Use a custom TreeMap implementation that tracks the list's numerical indices instead of scanning the whole list every time something gets added. The map keeps track of the next open numerical index as elements are inserted and removed, so adding to a list no longer has to walk through every existing entry looking for a gap.
In the common case where the list indices are consecutive, adding an element just appends it to the end immediately. If there are gaps from deleted entries, the map reuses the lowest available numerical index instead. This brings list addition down from O(n) to effectively O(1) in the best case, while still avoiding the full scan that made the old design so slow.
With this implementation, adding 1 million elements to a list takes ~1.5 seconds on my machine, that's over a 70,000% improvement over the old design!
Deleting
Deleting a list now sets it to null, and the TreeMap implementation now keeps track of the sublist indices, so it only loops over the necessary indices rather than walking the entire list each time
Testing Completed
IndexTrackingTreeMapTest.javaSupporting Information
Benchmarks:
Completes: #891
Related: #891
AI assistance: Junie was used to generate the majority of test cases