Slight freeze every 5 seconds (or so)

[Violent Jeb]

Is this why parts don't want to "click" in the editor/VAB? I've had this problem for a LONG time. I've only been noticing spikes on launches since 1.0 (with the smoke on the pad, presumably)

[katateochi]

Is this why parts don't want to "click" in the editor/VAB? I've had this problem for a LONG time. I've only been noticing spikes on launches since 1.0 (with the smoke on the pad, presumably)

If by that you mean when you go to click on something and the game seems to not register your click then yes. But that will be an intermittent thing, only happening when your click/action coincides with a freeze (Garbage Collector activity).

So....as an update to my observations on this;

I've given up with my career with tons of inflight craft and I've been messing about in sandbox with just a handful of craft (mostly just testing out designs and doing simple one craft missions) and in this sandbox (with graphics turned up and a couple enhancement mods; scatterer and EVE) the freeze is still there but it's not such a problem.

So clearly it has a lot to do with in-flight craft. While the unity5 upgrade may not do much to improve the actual GC, I assume that other craft (ie ones outside of your current 2.2km focus) will be running on separate threads so I hope that will actually do quite a lot to help this problem. Do you guys think that will/could be the case?

Also, will the GC be running as a separate thread?

[John FX]

If by that you mean when you go to click on something and the game seems to not register your click then yes. But that will be an intermittent thing, only happening when your click/action coincides with a freeze (Garbage Collector activity).

So....as an update to my observations on this;

I've given up with my career with tons of inflight craft and I've been messing about in sandbox with just a handful of craft (mostly just testing out designs and doing simple one craft missions) and in this sandbox (with graphics turned up and a couple enhancement mods; scatterer and EVE) the freeze is still there but it's not such a problem.

So clearly it has a lot to do with in-flight craft. While the unity5 upgrade may not do much to improve the actual GC, I assume that other craft (ie ones outside of your current 2.2km focus) will be running on separate threads so I hope that will actually do quite a lot to help this problem. Do you guys think that will/could be the case?

Also, will the GC be running as a separate thread?

My hope is that they will split the code up into as many parts as they are able to to fully exploit multithreading and that this will hopefully reduce GC stutter and stutter from multiple flights to levels we can`t notice in normal gameplay.

I get the impression that the GC is a unity thing and hopefully that will be optimised in U5. If I am wrong I hope Squad pull their finger out during the U4->U5 upgrade and fix their own code.

[TheTom]

GC is a Mono thing and nothing there will change in Unity 5 - as they are not upgrading the Mono version. A concurrent GC (that is not stopping the program) has been part of .NET for quite some time in the MS version. The solution in UNity is - not to produce garbage. Simple as that. At least not to do it too much. Given that a spaceship is static in parts, there is no reason to generate tons of new objects - those are simply bad programming practices, unsuitable for real time work. A decent memory profiler should be able to analyze that, but I am not sure there is one for Unity3d. I know some for .NET (I do high performance near real time development in .NET for a living) and they can show me exactly where the objects are created. But then the programmer must - rewrite things to fix the bugs.

A mono update is not in 5.0 - but I hope they retire mono for 6.0 and use the open source free microsoft runtime.

[Violent Jeb]

If by that you mean when you go to click on something and the game seems to not register your click then yes. But that will be an intermittent thing, only happening when your click/action coincides with a freeze (Garbage Collector activity).

Yup that's definitely the problem i'm having. Intermittently, the game will not choose a part out of the part list when i click on it. Other times it seems like parts won't stick on a given mouseclick, which is particularly noticeable with fuel lines or struts. When this happens, I have jogged the mouse around a bit, released whatever part i was holding, pick it up to "confirm" my clicks are working.. then within a few clicks it happens again.

Oftentimes I end up thinking my mouse/keyboard is the culprit but it has only seemed to be an issue with KSP!

I have found that certain things seem to help. "grabbing"/rotating the camera with the mouse seems to ensure the next few clicks are reliable. additionally, to overcome some of these challenges in the VAB (i'm sorry fortunately it's not a huge problem for me out of VAB), i have found that "extended" mouse clicks, where i "hold" my left clicks down, seem to work better (maybe the mouseclick is being recieved over multiple frames (where it might be frozen one moment and out the next).

Either way, let's hope for a fix!

[katateochi]

My hope is that they will split the code up into as many parts as they are able to to fully exploit multithreading and that this will hopefully reduce GC stutter and stutter from multiple flights to levels we can`t notice in normal gameplay.

I get the impression that the GC is a unity thing and hopefully that will be optimised in U5. If I am wrong I hope Squad pull their finger out during the U4->U5 upgrade and fix their own code.

yeah the GC is part of unity, but as TheTom says, it's not getting updated in Unity5. I heard somewhere that there may be a few tweaks to it, but nothing as exciting as a new one. So yes, the onerous is on Squad to fix their code. I sort of doubt we will see much of that in the initial release onto Unity5, infact I expect to see lots of things broken, but maybe the multithreading will compensate (maybe I'm just getting cynical!)

GC is a Mono thing and nothing there will change in Unity 5 - as they are not upgrading the Mono version. A concurrent GC (that is not stopping the program) has been part of .NET for quite some time in the MS version. The solution in UNity is - not to produce garbage. Simple as that. At least not to do it too much. Given that a spaceship is static in parts, there is no reason to generate tons of new objects - those are simply bad programming practices, unsuitable for real time work. A decent memory profiler should be able to analyze that, but I am not sure there is one for Unity3d. I know some for .NET (I do high performance near real time development in .NET for a living) and they can show me exactly where the objects are created. But then the programmer must - rewrite things to fix the bugs.

A mono update is not in 5.0 - but I hope they retire mono for 6.0 and use the open source free microsoft runtime.

This tallies with what I've read in posts from other Unity developers. The key being not creating/destroying objects during game play, but to create a pool of required objects which are accessed as needed.

Squad really needs to clean this aspect of the code up, it has become an absolutely vital optimization.

Yup that's definitely the problem i'm having. Intermittently, the game will not choose a part out of the part list when i click on it. Other times it seems like parts won't stick on a given mouseclick, which is particularly noticeable with fuel lines or struts. When this happens, I have jogged the mouse around a bit, released whatever part i was holding, pick it up to "confirm" my clicks are working.. then within a few clicks it happens again.

Oftentimes I end up thinking my mouse/keyboard is the culprit but it has only seemed to be an issue with KSP!

I have found that certain things seem to help. "grabbing"/rotating the camera with the mouse seems to ensure the next few clicks are reliable. additionally, to overcome some of these challenges in the VAB (i'm sorry fortunately it's not a huge problem for me out of VAB), i have found that "extended" mouse clicks, where i "hold" my left clicks down, seem to work better (maybe the mouseclick is being recieved over multiple frames (where it might be frozen one moment and out the next).

Either way, let's hope for a fix!

That's interesting that you get it worse while in the editors and less when in flight. Are you running lots of mods?

It might be interesting if you run Padishar's monitoring tool while in the editor and see if the spikes in its graph correspond to your clicks not being heard.

here's a link to a post a few pages back with a link to the tool

Once you open it you need to adjust the precision to 0.125s.

I expect you will see a pattern something like this and you'll probably find a correlation between the spikes and "bad clicks".

[Padishar]

It might be interesting if you run Padishar's monitoring tool while in the editor and see if the spikes in its graph correspond to your clicks not being heard.

here's a link to a post a few pages back with a link to the tool

Once you open it you need to adjust the precision to 0.125s.

I expect you will see a pattern something like this and you'll probably find a correlation between the spikes and "bad clicks".

The post you've linked is my tool for displaying frame times but your instruction about 0.125s and the screenshot are referring to GCMonitor which is Sarbian's.

[katateochi]

The post you've linked is my tool for displaying frame times but your instruction about 0.125s and the screenshot are referring to GCMonitor which is Sarbian's.

Oh, oops, sorry about that, must have had my brain in backwards or something. I should not post when really tired!

[rkman]

While it is heartening to see the community go at these problems with such gusto, I'm seeing zero communication from the people who actually have a good chance at fixing it.

There is a post by HarvesteR on the Unity forum complaining/asking about the stutter. So it seems they are aware of the problem, but they can't really fix it because it is a Unity/Mono thing.

Would be nice though if they (specifically the moderators who help in this forum) would acknowledge the fact that the user also can not fix it. At best the user can do a few things that make it a little less bad. (psa: never force ksp to run on only one core, that makes the stutter worse).

Hopefully Squad follows this discussion anyway and can benefit from suggestions done by some apparently knowledgable folks: given Mono's shoddy GC, go out of your way not to create garbage (which seems to be in principal feasible with KSP).

[kpstjeev]

I don't have noticeable freezes with stock KSP, they are there but under 60ms.

On modded install I get from 180 to 400 ms freezes every 10-15 seconds, which are obvious and annoying.

Not sure if this was mentioned in this thread: http://forum.unity3d.com/threads/mono-garbage-collection-can-i-get-a-summary.228199/

Basically there is discussed that the current Unity (or more likely outdated Mono that is used by unity) is using GC algo with performance level in the opposite direction of "optimal".

The more references are in the heap the more time it takes to sweep through all of them, and this is only way it knows how to do garbage collection.

It also seems that Unity is not going to be upgrading Mono any time soon.

IL2CPP, which comes with U5, could be a solution.

http://blogs.unity3d.com/2015/05/06/an-introduction-to-ilcpp-internals/

It will be shipped with Boehm GC, which generational type GC, not to mention overall performance boost from running code natively.

EDIT:

Nvm...

On the GC issue, the Boehm-Demers-Weiser garbage collector is used for IL2CPP on both 4.6 and 5.0. It does replace the Mono GC, but this is effectively the same GC used for Mono in Unity before. We’re using a newer version of the source code for the GC, but it still has the same features and behaviors. So I don’t think there is much you can do from the C# level to improve GC performance.

We are investigating the use of the Microsoft GC that is a part of the CoreCLR, but we don’t have anything ready on that front yet. We’ll also have a blog post in this series about the GC coming up soon.

Edited October 24, 2015 by kpstjeev

[cfds]

I still do not understand why they use a garbage collector at all. What is wrong with just writing clean code?

[ANWRocketMan]

Writing perfectly clean code is nigh impossible. Not to mention it would probably require a rewrite of a LOT of the game's code. A task which i don't imagine the devs taking on soon, if at all.

[Padishar]

I still do not understand why they use a garbage collector at all. What is wrong with just writing clean code?

Given the game uses the Unity engine which is based on Mono, they have no choice as that is simply how memory allocation works in Mono/.NET language runtimes. The word garbage has no connotation of "not clean", it simply refers to a piece of memory that is no longer being used by the program.

[sal_vager]

Also the garbage collection is automatic and can't be disabled, and each time the GC runs it checks for all reachable objects and deallocates the areas of memory in the programs heap that didn't have a reachable object in it, this obviously takes time and if most objects are still in use then the memory released is small.

More info here.

[cfds]

Given the game uses the Unity engine which is based on Mono, they have no choice as that is simply how memory allocation works in Mono/.NET language runtimes. The word garbage has no connotation of "not clean", it simply refers to a piece of memory that is no longer being used by the program.

Since KSP is the poster child for memory leaks, this garbage collector seems be, well, garbage. Or does the garbage collection only happen in the GUI classes and the memory leaks are written by SQUAD in C++ in the more basic code?

[sal_vager]

While it is true there was a memory leak with the 3rd party code used to warn the player of overheating parts in flight, that has already been resolved.

As was already said, the garbage collector will still run even if there is little or nothing to collect, currently it is doing a fine job collecting the few megabytes left over by the older Unity UI object draw calls, which you can see yourself in the debug screen, performance tab.

These draw calls will also be resolved in Unity5 with the unified UI, but the GC will still run because it's automatic, and while KSP does use a lot of RAM this is not the same thing as a leak, so "cleaner code" won't make a difference.

Also, these GC runs are on the order of milliseconds and are hardly game breaking, they are more a slight annoyance than anything else.

You seem to be basing your opinions on old information and incorrect assumptions here, it might help if you learned a bit more about memory leaks, garbage collection and why computers use them to manage memory.

[ANWRocketMan]

I have noticed that GC stutters are a lot less noticeable when I play the game on Linux.

[Torgo]

After about a week of playing on 64 bit Linux, I started to get this issue today. I made sure all my drivers are up to date, and even uninstalled a few mods, but the game pauses every couple of seconds for about a tenth of a second.

It's not a PC issue, though, because I did a fresh install, no mods, in a different folder of the same machine, and it works flawlessly. So the issue is in a mod, someplace, but nailing it down is proving to be harder than I figured. I removed the mods I installed just before the issue started, but the issue remains.

I'm going to end up just making another new install and start over. The game is unplayable in this state.

[Padishar]

Did you run the same save in the clean install? This effect may just have become obvious due to the complexity of the save rather than the mods (though it could well be made worse by one or more garbage happy mods).

[Torgo]

Did you run the same save in the clean install? This effect may just have become obvious due to the complexity of the save rather than the mods (though it could well be made worse by one or more garbage happy mods).

The stutter was happening before a game was even loaded. It was apparent on the startup menu screen.

I loaded up my suite of mods via CKAN on a copy of the fresh install, the stutter returned having never started a new game. I removed Planetshine, and the stutter also went away, which is weird, because I've had planetshine installed for quite a while before this started happening.

I'm testing my saved game now to see if removing planetshine fixes it. (edit - no, removing planetshine wasn't enough. Still a distinct stutter on the menu screen. Next test is switching Hi Res EVE for Low Res EVE.)

Edited November 1, 2015 by Torgo

[cpx]

Anyone know how to change garbage collection timer so it will be longer? I hate those lags, playing with mods is just too much fun. So i wanna tune it so it will lag less.

[Padishar]

33 minutes ago, cpy said:

Anyone know how to change garbage collection timer so it will be longer? I hate those lags, playing with mods is just too much fun. So i wanna tune it so it will lag less.

If you had read this thread (or any of the others about the same subject) you would know that it isn't possible (at least not without some seriously nasty hacking of the unity player).

[cpx]

I'm willing to do just that. Soooo where do i start?

[Padishar]

1 hour ago, cpy said:

I'm willing to do just that. Soooo where do i start?

It would be a breach of the KSP EULA and, as such, is not allowed to be discussed on this forum.  In any case, unless you have significant knowledge and experience of this sort of thing you are unlikely to get very far and if you do have such knowledge and experience you would just work it out yourself or, more likely, decide that it really isn't worth the bother.

[cpx]

Trying to fix bugs/improve game experience is against EULA? Strange. Anyway got link to some forum that is willing to discuss this? Send with PM.

Edited May 19, 2016 by cpx