FlightIntegrator and friends micro-optimization Round 2#257
Merged
Conversation
…nly relevant in large part count situations. More can be done : I didn't touch yet stuff specific to aero situations (drag, conduction occlusion...) and there is probably something to be done about Integrate()
…cro-optimizations for various pieces of code running every frame on every part. Won't do much in low part count situations, and some patches are highly situational (atmospheric flight, docking ports, struts, particles repositionning on floating origin shifts...) Patches affecting the FlightIntegrator and VesselPrecalculate are broably incompatible with mods trying to override/extend stuff through MFI. There are a bunch of perf issues with "end of the call stack" methods being inefficient because they do extra work that is already done at the call site or can be made faster by using state from the call site, so patching those methods doesn't cut it, but this mean many stock methods aren't called anymore, so if those methods are replaced/prefixed/postfixed with MFI, things will break. Notable examples are FI.UpdateAerodynamics() and FI.Integrate(Part). This could probably be avoided at the cost of some of the perf gains, but I wanted to see how far things could be pushed perf wise. On a side note, there is a bug lurking in the VesselPrecalculate.CalculatePhysicsStats reimplementation, not sure what it is exactely but a side effect is camera target being wrongly offset. Likely something with the CoM calcs.
-most notably this caused the camera to be anchored to the wrong place
…cro-optimizations for various pieces of code running every frame on every part. Won't do much in low part count situations, and some patches are highly situational (atmospheric flight, docking ports, struts, particles repositionning on floating origin shifts...) Patches affecting the FlightIntegrator and VesselPrecalculate are broably incompatible with mods trying to override/extend stuff through MFI. There are a bunch of perf issues with "end of the call stack" methods being inefficient because they do extra work that is already done at the call site or can be made faster by using state from the call site, so patching those methods doesn't cut it, but this mean many stock methods aren't called anymore, so if those methods are replaced/prefixed/postfixed with MFI, things will break. Notable examples are FI.UpdateAerodynamics() and FI.Integrate(Part). This could probably be avoided at the cost of some of the perf gains, but I wanted to see how far things could be pushed perf wise. On a side note, there is a bug lurking in the VesselPrecalculate.CalculatePhysicsStats reimplementation, not sure what it is exactely but a side effect is camera target being wrongly offset. Likely something with the CoM calcs.
Contributor
Author
|
This is the other set of changes from #230 |
…atic" patches, fixed a few things, added a bunch of library methods for querying part modules, models and renderers.
- Small refactor of BasePatch for better error handling and avoiding the "this" boilerplate - Various small improvements for the FlightCoreSystemsPerf patches
…fficult to get right than anticipated. But after a lot of testing, I think I finally got it right.
…t code on drugs, kids !) - Refactored the FI & VesselPre patches to make them MFI-compliant. They should no longer interfere with mods using MFI such as FAR.
…emperatureGaugeSystem.Update() - Updated readme and settings.cfg
Contributor
|
So, I feel this is ready for a (pre)release. Compatibility with MFI and relevant plugins using it (FAR, KerbalWeatherProject, AdvancedAtmosphereTools...) has been fixed, although not tested extensively, but I don't foresee issues here. The various perf fixes have been reorganized into various "thematic" patches :
There are two other (not really related) changes in this PR :
|
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
2 participants
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.
Many experimental perf improvements, basically a big collection of micro-optimizations for various pieces of code running every frame on every part. Won't do much in low part count situations, and some patches are highly situational (atmospheric flight, docking ports, struts, particles repositionning on floating origin shifts...)
Patches affecting the FlightIntegrator and VesselPrecalculate are broably incompatible with mods trying to override/extend stuff through MFI. There are a bunch of perf issues with "end of the call stack" methods being inefficient because they do extra work that is already done at the call site or can be made faster by using state from the call site, so patching those methods doesn't cut it, but this mean many stock methods aren't called anymore, so if those methods are replaced/prefixed/postfixed with MFI, things will break. Notable examples are FI.UpdateAerodynamics() and FI.Integrate(Part). This could probably be avoided at the cost of some of the perf gains, but I wanted to see how far things could be pushed perf wise. On a side note, there is a bug lurking in the VesselPrecalculate.CalculatePhysicsStats reimplementation, not sure what it is exactely but a side effect is camera target being wrongly offset. Likely something with the CoM calcs.