Initial implementation of GetObjectByTag optimization, should help th… #1538
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
…e LookupTable spikes too.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
…e LookupTable spikes too.
The main advantage here is that this PR heavily reduces time spikes spent when inserting or removing objects (e.g. creating or deleting any object with a tag). When the tag array grows large enough (Arelith is 200k+), inserting or removing tags near the start of the array cause the whole array to be shifted in either direction, which can lead to multiple second long spikes when done in a loop.
This change instead reduces that spike to objects that share a tag - perhaps still not ideal, but no longer disastrous. Based on the results I get from profiling this on Arelith, I may move to a more fine-grained approach like using chunks of object IDs so that the cost is fixed, or linked list, both of which would exchange lookup performance for insert/remove performance.
Untested beyond my toy module, but it seems to work. Side effect; Arelith module load time from 20s -> 5s. I'll convert from draft to real PR when I've tested it more.