[PORTS] Garbage Collection Optimizations #2435
Merged
Conversation
This file contains 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
## About The Pull Request Adds a proc that types can override to inject extra information into the refsearch This'll allow us to more easily track and deal with refs held by general datums, like callbacks. I've implemented a template example FOR callbacks, to provide an example and assist in solving future issues Done to help lumipharon from TGMC, they were having trouble with this case. This isn't perfectly optimized, but this proc has a LOT of issues just in general. Need to rework it to cut down on string churn someday
Alllright so reftracking is slow, really really slow. That's a problem for me, both because I want it to be fast so I can more efficiently torture players by running it on live, but also because it impedes both local and CI runs. So I've set out to micro optimize the DoSearchVar proc, one of the hottest in the game. I've done this in a few different ways. Removing redundant proc args Yeeting assoc arg setting (extra cost) Moving if statements around to prioritize the more common case Ignoring empty lists. Throwing our snowflake list checking into the sun (Background, byond has some special lists that cannot be accessed like an assoc list, trying to will lead to runtimes) The way we handle this involves inspecting their ref string, and it eats a LOT of time. Faster then to mark all the lists we know are special by var name, and then use try/catch to detect and silence anything that sneaks through (this is on the order of like 1/3 per run, kinda curious what they are tbh) Thanks to MSO for the idea for this btw. Removes the vars and logic that tied ref searching to clients. It's not how this code is used, and it slows everything else down for really no reason Added support for handing in a known "hanging reference" count, and then searching for that. This lets us early exit the ref search if we find everything we were looking for, which is REALLY powerful, and why I asked for refcount() in the first place. [Fixes some harddels w gulag stuff born of the 515 one way ref issues](tgstation/tgstation@046d7da) [Ensures proximity cameras clean their ref to their proximity datum if it's deleted](tgstation/tgstation@ff607e9) [Deleting a pipe connected via the gas_machine_connector datum to a machine should also delete that machine (harddel fix)](tgstation/tgstation@9eecca2) All this combined speeds up refsearching massively, on the order of hundreds of seconds, and makes it far less time consuming for both CI and running on live. I'll be bullying some servers semi soon, want to see what I can cut out.
LikeLakers2
deleted the
project/ports-submitted/garbage-collection-optimizations
branch
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.
About The Pull Request
This PR ports the following PRs:
The intention with these ports is to reduce the amount of time Integration Tests take on our codebase. Currently, our integration tests take somewhere around ~13 to 20 minutes (usually at one extreme or the other) to complete per map - but with these ports, the time is now typically between ~10 to 15 minutes (usually sticking at around 11 or 13 minutes) per map.
Only three outliers were spotted during my testing, which consisted of rerunning the CI Suite workflows on a single commit 10 times (see https://github.com/LikeLakers2/Monkestation2.0/actions/runs/9691442350). These outliers do not appear to be related to these commits.
Because of the nature of these optimizations, I also believe they will improve server performance during regular gameplay.
Why It's Good For The Game
Reduces the amount of time we spend running Integration Tests on Github Actions, and potentially improves game performance too.
Changelog
No user-facing changes, except for performance improvements.