Faster implementation of TemperatureGaugeSystem
#270
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
- Minimal update overhead when no gauges are active/shown - Vastly reduced update overhead when gauges/highlight are active/shown - Gauges are now instantiated on demand, eliminating (most of) the cost on vessel load - Gauges are now recycled when the vessel is modified / switched, instead of destroying and re-instantiating them immediately
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.
Address issue #194
Complete reimplementation of
TemperatureGaugeSystem:Gauges were previously always instantiated for every part on the active vessel, and this was pretty slow due to triggering a lot of internal UI/layout/graphic dirtying on every gauge instantiation. Overall, the operation can take several hundred milliseconds in not-so large part count situations, leading to very significant hiccups in most vessel events involving a part count change and on active vessel switches, as well as on flight scene loads.
Some profiling data :
TemperatureGaugeSystem.Updateaverage frame time with a ~500 part vessel, gauges not shown : Stock 0.6%, KSPCF 0.04%TemperatureGaugeSystem.Updateaverage frame time with a ~500 part vessel, ~16 gauges shown : Stock 1.7%, KSPCF 0.3%Note that we were already patching
TemperatureGaugeSystem.Updatewith only a mild mitigation of the update overhead when gauges weren't shown. This is a much deeper hack changing the whole lifecycle and handling of the stock objects involved, and consequently any mod trying to interact with them will likely break. A github search didn't return anything, and I don't see any use case for such interactions, so probably alright ?