KSP Performance again

[boxman]

This just shows that something has gotten ALOT worse over the last few versions.

There was a time when you could run up to a thousand parts before it would start dipping to 10fps or lower.

Now it seems like even high end computer struggle with 200-300 parts, even though that once ran smooth with nearly all systems.

I personally feel this started becoming noticeable around the time when KSP started using fake fullscreen.

This is probably more noticeable to those of us who have taken long breaks..

[Terwin]

I totally agree here. KSP performance has drastically worsened and Squad remain tight lipped on the issue. This is a major problem that needs fixing. As currently I can only see the game running slower and slower.

On the issue of GC stutter, two years ago when this issue raised it head I did a 30 second google search and discovered many other Unity devs with the same issue. they fixed it by using a third party UI program.

The stutter in Unity is caused by the UI GC. If Squad changed the UI the issue would most likely be resolved as others have done so successfully.

In that case it sounds like the complete re-work of the UI for 1.1 should solve the stuttering problem.

Performance on the other hand is a much harder problem.

Especially when so many are complaining about/asking for better aerodynamics.

Any time you ad more detail/precision to a physics engine you will be slowing it down as there is more work do be done.

While almost any code can be optimized to a certain degree, you get diminishing returns. You also tend to get harder to maintain code as well as often being buggier.(Example: when you saftey-check everything in each function it can take much longer to process but you will get fewer unhandled exceptions, if you remove all the checking that is 'not currently needed' then any tweak/improvement you make in the future can easily break your system because you forgot to check something that can now be an unexpected value)

As optimization and stability are often an either/or proposition, I would suggest that any performance optimization beyond the low-hanging fruit variety should probably wait until the stability is a little better(unless you happen to think that the current stability of KSP is good enough that it can afford to be reduced by Squad doing an optimization pass)

While a project that as been built up with an iterative process over a long period will often get both speed and stability improvements from a through code-refactoring, this is something that Squad already said they were doing for 1.1, so asking for speed optimizations beyond what is already being done is not likely to be good for stability.

[ajburges]

I also noticed a performance hit with 1.x.

My .90 SSTO of choice was a 200-250 part (payload dependant) Mk2 monstrosity. Huge wings, 2x intake spam, fuselage as structural components. My current cargo SSTO has 120 parts and Mk3 scale, but lags in space and cripples my computer in atmo (luckily it flies well). Can't wait to unlock huge wings in career mode. I don't need the lift, just the part count savings. At least I don't dink about with rendezvous in low atmo.

Given that I have a over 5 year old 2 Xeon system. Any mention of multi-threading makes me excited. Even if it's one thread per ship. I've done 4 ship rendezvous before involving 2 of my current cargo haulers in development. Thank god for Docking Alignment Indicator.

[Nigeth]

Especially when so many are complaining about/asking for better aerodynamics.

FAR and DRE combined don't affect performance as much as the stock physics model so I'm not convinced that it's simply an issue of complexity.

[Padishar]

In that case it sounds like the complete re-work of the UI for 1.1 should solve the stuttering problem.

The UI is not the only cause of garbage collection stutter. From the tests that I have run I believe the stock UI to be a fairly minor part, especially when large vessels are involved. As for mods, Unity's GUI/GUILayout API that most mods use makes it very easy to generate stupid amounts of garbage though, with careful coding, it is possible to reduce the effect on performance to barely measurable levels.

Performance on the other hand is a much harder problem.

Especially when so many are complaining about/asking for better aerodynamics.

Any time you ad more detail/precision to a physics engine you will be slowing it down as there is more work do be done.

While almost any code can be optimized to a certain degree, you get diminishing returns. You also tend to get harder to maintain code as well as often being buggier.(Example: when you saftey-check everything in each function it can take much longer to process but you will get fewer unhandled exceptions, if you remove all the checking that is 'not currently needed' then any tweak/improvement you make in the future can easily break your system because you forgot to check something that can now be an unexpected value)

It certainly wouldn't be a case of diminishing returns to replace several "O(n^2) every time" algorithms with ones that are a reduced O(n^2) occasionally but O(n) most of the time.

Parameter validation (and other safety checks) catch lots of bugs during development and also allow for clean handling of unexpected situations in a released program. It only really makes sense to remove them from hot code (code that is called very often) and, even then, the usual practice is for them to remain in development builds unless they drastically impact performance.

As optimization and stability are often an either/or proposition, I would suggest that any performance optimization beyond the low-hanging fruit variety should probably wait until the stability is a little better(unless you happen to think that the current stability of KSP is good enough that it can afford to be reduced by Squad doing an optimization pass)

An optimisation that reduces stability is not an optimisation, it is a new bug and should be caught and fixed before release. I don't think that the current stability of KSP is good enough. I, personally, would classify the issues with the new heat system, the issues with the claw and the major memory leaks (and a few other, long-standing, serious bugs) as being "drop everything, including U5, until these are hot-fixed", but it does make a certain amount of sense to do the Unity 5 port, a dead code clean-up and some significant optimisations before addressing the bulk of the bugs. Yes, there would be new bugs, but quite a lot of the current bugs would no longer be relevant (and the really serious bugs would have been previously hot-fixed).

While a project that as been built up with an iterative process over a long period will often get both speed and stability improvements from a through code-refactoring, this is something that Squad already said they were doing for 1.1, so asking for speed optimizations beyond what is already being done is not likely to be good for stability.

If it doesn't then why are you refactoring it? Even if the refactoring is forced due to an API change (as some of the KSP/Unity5 stuff is) you would still try really hard to make sure it was no worse. As I said before an optimisation that reduces stability is a bug and should not be released, either fix it or roll-back the optimisation.

[Nigeth]

Refactoring code only works if you have a robust unit test/regression test framework in place that covers most of the critical parts of your code base. Parameter validation, safety checks and other debug artifacts shouldn't be active in a production compile anyway. Don't confuse debug assertions and run-time checks used for test automation with exception handling. The former should be removed in release versions of your SW the latter can't.

Performance evaluation of non-UI code is trivial and should be covered by any sort of decent profilling package and most memory leaks can be detected by Valgrind or a similar solution. Add a tool for static code checking (like PC lint or QAC) into the mix and you have an extensive and complete set of tools to evaluate the performance of new or refactored code, to do automated testing and regression tests and to find most of the stupid but common bugs everyone of us does. If you can randomize tests you're even better off. The rest is the responsibility of the testing team.

The fact of the matter is that if Squad had a comprehensive and robust set of test and performance evaluation tools in place then a basic and easy to find bug like the heat shield bug in 1.0.3 should have never ended up in the released version. The same with the overheat indicator UI and memory leaks Valgrind or a similar tool would most certainly have found that issue. These are bugs that at least one of the testing stages should have caught. If no one else than at least the system test guys.

In that context I'm not convinced that the current performance baseline of KSP is simply a matter of the complexity of the calculations involved and not also an issue of an implementation that could use additional optimization work.

- - - Updated - - -

Take the new heat physics for example. The new calculations should have been tested with different ships and component configurations. They should have been tested with massless parts. They should have ben tested with clipped parts. They should have tested what happens when you migrate an existing save from 1.0.2 to 1.0.3. There should have been a performance evaluation of the new equations and models especially on complex vessels with many parts

The fact that most runaway overheating failures of ships happen with massless parts, clipped parts or on migrated saves shows that they didn't test that or they were not thorough enough. Even though those are basic use cases.

This makes me think that there is still a lot of potential for optimization in the existing code basebefore we hit some sort of performance ceiling.

[fisto roboto]

right

did some testing. the fps numbers are eyeballed averages, so take them with a grain of salt and +-5 fps! i took the same 145 parts ssto and flew a standard climb to orbit insertion consisting of standstil on the runway, climb to 10km, shallow acceleration to around 19km and 1250m/s, switch to mainsail and 20° attitude untill AP of around 85km and meco. aerodynamic fx quality low.

condition before: runway fps 22, ascent fps 15, acceleration fps single digit, meco fps between around 20

* switch between windowed and fullscreen - no effect

* making an exception in avira antivirus for ksp exe and process - no effect

* disabling intel speedstep in bios and forcing cpu to 4.1ghz - MASSIVE improvement to runway fps 55, climb fps 45, acceleration fps 25 decreasing gradualy to 15 durring acceleration phase, meco fps 30

* increasing aero fx to normal - lose 2-3 frames on average during acceleration comperd to speedstep

* decreasing aero fx to very low - gain 2-3 frames during acceleration compared to speed step

* decreasing aero fx to minimal - gain 2-3 frames to a total of around 20 fps during acceleration

* flying the same profile with another ssto with 190 parts, similar size and design philosophy and a lower lifting-non lifting part ratio - lose around 4 fps during all phases of flight

my own personal conclusions from this:

1. turn speedstep off! closely observing core clock i was shocked that the cpu ran at idle 1.2 ghz with the plane standing on the runway and the game at 22 fps. loading a save in witcher3 got the cpu up to 3.2 ghz as did one or two prime95 threads. 12 theads brought it up to 4.1 ghz. when i turned speedstep off, ksp transformed to a different game! i actualy realized that ive played the game at half time speed up untill now. i will have to get used to not being able to roll a cigarette during climb. so speedstep will stay off from now on. particularly because cpu idle temp is the same 37°c as before.

2. aero fx impacts your performance significantly. between off and normal i get allmoast 10 fps during acceleration, so this will stay off as well

3. i suspect heating to be a huge performance hog! even with all aero fx off, i lose almoast 20 fps from climb to acceleration. also, fps is the the lowest during peak heating, and rises back up again to a level between climb and acceleration once i the plane leaves the atmosphere. when quiting ksp and reloading the same craft that just left the atmosphere, fps is back at 60+.

4. aero is probably not as bad of a hog. the drop from idle at the runway to 40° climb, is around 10 fps and not really noticable when not looking at the counter. the drop from climb to peak heating is another 20 fps and the game runs noticably slower.

--edit--

5. ah yes, and the game is still obscenly unoptimized at many levels

Edited July 7, 2015 by fisto roboto

[Red Iron Crown]

Good results, sounds like you'll be getting better performance from now on!

I believe you can turn off the heating system altogether in the Alt-F12 menu if you want to get some real data about #3.

[Padishar]

1. turn speedstep off! closely observing core clock i was shocked that the cpu ran at idle 1.2 ghz with the plane standing on the runway and the game at 22 fps. loading a save in witcher3 got the cpu up to 3.2 ghz as did one or two prime95 threads. 12 theads brought it up to 4.1 ghz. when i turned speedstep off, ksp transformed to a different game! i actualy realized that ive played the game at half time speed up untill now. i will have to get used to not being able to roll a cigarette during climb. so speedstep will stay off from now on. particularly because cpu idle temp is the same 37°c as before.