Performance issue: ProgressTracking.Update seems to be O(bodies * vessels) about kspcommunityfixes HOT 5 CLOSED

Er it's worse than I thought....the top-level seems to iterate over every vessel, and then over every ProgressNode.

...every CelestialBody seems to have 19 sub-nodes.

from kspcommunityfixes.

I didn't do a very thorough search, but it looks like none of the progress nodes' OnIterateVessel calls needs to do anything with a ship that isn't the active one, and none of the CelestialBody progress nodes need to do anything in OnIterateVessel either. So that's two places to easily skip work.

It could definitely cause issues if any mods add stuff in there though.

from kspcommunityfixes.

TBH, I would categorize that as "won't fix". KSP just doesn't scale well at all in some modded scenarios.

320 bodies is just silly. If a mod (or a player) want to do that, then it should be responsible for implementing such a case properly.

I can take a look, but it seem entirely normal for progress tracking to check all vessels, not only the active one. Not saying there isn't room for optimization while keeping stock functionality intact, but I think that having such a large amount of bodies will inevitably cause perf issues in many places, so I don't really see the point, and it's kinda out of the scope of KSPCF to deal with that.

from kspcommunityfixes.

Galaxies Unbound with all the optional planets is 100-200 bodies I think. And I'm pretty sure the stock code isn't excluding asteroids, flags, and debris.

from kspcommunityfixes.

I recognize my install is an extreme one, but this change increases my fps by ~50% (33% reduction in frame time) and I'm pretty sure it preserves all stock behavior (but please verify if you're concerned)

from kspcommunityfixes.