Implement numerical index tracking to optimize adding to lists#8519
Open
UnderscoreTud wants to merge 3 commits intodev/patchfrom
Open
Implement numerical index tracking to optimize adding to lists#8519UnderscoreTud wants to merge 3 commits intodev/patchfrom
UnderscoreTud wants to merge 3 commits intodev/patchfrom
Conversation
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
Solution
Use a custom tree map implementation that tracks the list's numerical indices and their positions. The implementation adds a shortcut if the numerical indices are consecutive, so for a best case scenario (no gaps in the indices), adding to a list will have a time complexity of O(1). If gaps are present on the other hand, the list will perform a binary search to find the next open slot, giving a time complexity of O(log n) for a worst case scenario. 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!
Testing Completed
IndexTrackingTreeMapTest.javaSupporting Information
Completes: none
Related: none
AI assistance: Junie was used to generate the majority of test cases