KSPModdingLibs/KSPCommunityFixes

Performance issue: OrbitRendererBase.LateUpdate is expensive in games with lots of bodies and vessels

JonnyOThan opened this issue · 2 comments

This is hitting about 6ms in my profile captures. I have about 1000 objects with orbits (mostly asteroids, but this isn't a crazy number if you have a lot of debris or are playing Galaxies Unbound). This code skips the heavyweight work when the map mode isn't open, but really we should just disable the updates on all these objects until the map or tracking station is opened.

(I'm working on this one)

Recap of the discussion in the closed PR : I don't think it's even worth it to disable MapObject instances. The base class has actually no OnLateUpdate() implementation, only ScaledMovement is doing something, and we can't disable those.

Profiling with ~54 scaledspace objects (stock bodies + a bunch of vessels and asteroids) gives the following results :
image
This is 0.01 ms of gains for 54 objects, so extrapolating a bit, even for a game with 1000 scaledspace objects, that's less than 0.2 ms avoided (and probably much less in a non-debug game, remember that all managed runtime optimizations are disabled here).

The only significant gains are from bailing out early of OrbitRendererBase.LateUpdate() :
image

Given that disabling MapObject instances is inherently risky, I think I will only implement early bail-out in OrbitRendererBase.LateUpdate(), as this account for 99% of the perf gains and is quite safe to do.

Awesome, I'll measure this in my save and see how it stacks up.