-
-
Notifications
You must be signed in to change notification settings - Fork 681
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Optimizes some gas_mixture procs, Optimizes pipeline processing signi…
…ficantly by 33% (#74233) It is faster to operate on a gas list, especially if cached, then it is to operate on a datum. Doing this cause I'm seeing cost in merge() post #74230 Hits on a few other important places too. self_breakdown and such. Worth it IMO Could in theory go further by caching the global list. I'm tempted I admit but it needs profiling first and it's late EDIT: I have not slept, and have gone tooo far [Micros /gas_mixture/copy and copy_from, adds a new proc to handle copying with a ratio, copy_from_ratio](tgstation/tgstation@91da000) [91da000](tgstation/tgstation@91da000) The ADD_GAS sidestep saves us 0.1 seconds of init (used to at least. Ensuring we don't break archive is gonna have a cost. I don't want to profile this so I'll estimate maybe 0.05 seconds). The faster version of copy_from is just well, better, and helps to avoid stupid [Optimizes pipeline processing](tgstation/tgstation@bf5a2d2) [bf5a2d2](tgstation/tgstation@bf5a2d2) I haven't slept in 36 hours. Have some atmos optimizations Pipelines now keep track of components that require custom reconciliation as a seperate list. This avoids the overhead of filtering all connected atmos machinery. Rather then relying on |= to avoid duplicate gas_mixtures, we instead use a cycle var stored on the mix itself, which is compared with a static unique id from reconcile_air() This fully prevents double processing of gas, and should (hopefully) prevent stupid dupe issues in future Rather then summing volume on the gas mixture itself, we sum it in a local var. This avoids datum var accesses, and saves a slight bit of time Instead of running THERMAL_ENERGY() (and thus heat_capacity(), which iterates all gases in the mix AGAIN) when processing gas, we instead just hook into the existing heat capacity calculation done inside the giver gases loop This saves a significant amount of time, somewhere around 30% of the proc, I think? This doesn't tackle the big headache here, which is the copy_from loop at the base of the proc. I think the solution is to convert pipelines to a sort of polling model. Atmos components don't "own" their mix, they instead have to request a copy of it from the pipeline datum. This would work based off a mutually agreed upon volume amount for that component in that process cycle. We'd use an archived system to figure out what gases to give to components, while removing from the real MOLES list. We could then push gas consumption requests to the pipeline, which would handle them, alongside volume changes, on the next process. Not sure how I'd handle connected pipelines... Merging post reconcile maybe? This is a problem for tomorrow though, I need to go to bed. Saves about 30% of pipeline costs. Profiles taken on kilo, until each reconcile_air hits 5000 calls [old.txt](https://github.com/tgstation/tgstation/files/11075118/Profile.results.total.time.txt) [new.txt](https://github.com/tgstation/tgstation/files/11075133/profiler.txt)
- Loading branch information
1 parent
8061855
commit 907c1f4
Showing
6 changed files
with
72 additions
and
29 deletions.
There are no files selected for viewing
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
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
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
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
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
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