Serious answer to the stutter issue.

[Rath]

Im sorry i had to get all angry to bring this out. But we obviously have a serious issue with the game. Peoples perceptions obviously have a lot to do with this problem.

Really, cause I've never seen it even on my heavily modded instal... (KAS KIS NFT KW...) On a old desktop.

[westy]

I had some awful stuttering in several, but not all, modded installs on a decent PC from 0.23 to 0.90. Every few seconds the audio and game would freeze/unfreeze. It was very unpleasant.

However as other people have mentioned, the problem has all but gone in 1.04, my current career mode is coming to a close, and I have not noticed stuttering as yet.

It is worth noting that I terminate all ships, probes and debris once their mission is complete.

[steve_v]

It is worth noting that I terminate all ships, probes and debris once their mission is complete.

I don't, which may have something to do with it.

It's at the point in a save where I have a bunch of off-world bases and stations in play that the stutter drives me away - I'm at this point again now, and it's all but unplayable for me.

Hence the playing forum-kerbal and moaning about this issue.

As I have commented in one of the other (numerous) threads on this issue, it appears to scale with size of save - i.e. number of active flights and debris (at least in my case, YMMV). Even having flags scattered around the system seems to contribute.

Mods make a big impact, particularly MechJeb*. But even in a bone-stock game I see the stutter, once I have a few missions in progress.

Deleting all my debris makes for some improvement, albeit a short-lived one.

I have been suffering with this as long as I can remember - at least as far back as 0.16. I'd happily suffer a while longer in an early-access or beta game, but it's getting beyond a joke now - we're at 1.x and the game still feels like a tech-demo, creaking away on an outdated engine with memory leaks, bugs, and performance problems everywhere.

I'm still thinking this must be a perception / expectation issue, I've seen it on two radically different hardware configurations myself, and many more configurations via the forum. Once noticed it cannot be un-noticed.

* I did poke sarbian about this at some point, complete with frame-time graphs 'n stuff. He indicated he would look into it, and this may well be what motivated the development of GCMonitor.

- - - Updated - - -

The audio-stutter was fixed some time back, but I have a suspicion that the root cause (GC issues) has not been addressed - rather the audio playback moved out of the loop, so to speak.

[SessoSaidSo]

Regardless if you do or do not experience this problem (or take the time in your save to notice this problem) the fact that this thread has generated over 1400 views in under 4 day should signal to the dev team that this is an issue with which a not insignificant portion of the community is struggling with. To be honest at this point a lack of response on this topic from the team would be in my view, a very serious failure on their part.

[sal_vager]

but I have a suspicion that the root cause (GC issues) has not been addressed

I'm actually going to throw out a new theory here, seeing as this stutter has been reported by people with one part, no addons, on the launchpad (so no terrain PQS to worry about) and lowest settings, it's even been spotted in the VAB.

It's not the garbage collector.

Sorry, but i can't test your sample, since it's a 64bit build and i still have a 32 bit system

Anyways... In general using FixedUpdate will always cause jitter as FixedUpdate runs at a different interval as the visual update. Same for anything physics related (FixedUpdate is actually run by the internal physics catch-up loop).

LateUpdate and Update actually should be quire similar except it's movement is based on another scripts Update as this would be a dependency-chain and you would have to specify the order in which the Update routine should be called. LateUpdate usually solves such problems since it is called after all Updates.

It's not a "bug" in Unity. The FixedUpdate jitter is a known and expected behaviour due to the "fixed" update.

If you see jitter when using LateUpdate, that jitter comes from sources outside Unity, most likely the OS or other software that runs in parallel. Things like that could cause framerate fluctuations which you might notice as jitter.

Also, stutter is reported all over the Unity forums on all platforms, here, here and =1"]here, even in the simplest of scenes, and no one has a fix that works.

Garbage collection cannot be the issue when a project with one object displays stutter, there's nothing to collect, that it is occurring at or close to the same time is not enough correlation, but we know KSP is a physics-intensive game, and people have had some luck minimizing their stutter by fiddling with their v-sync, it's likely their physics and their visual updates are occurring much closer together.

These are things in the CPU stack (the CPU still needs to send stuff to the GPU) where any delay is going to be noticed, the GC runs in the stack when it has a free moment and just zips through the heap freeing up anything it finds with no references, a free moment it gets when the visual updates are catching up to the physics.

Now, as I already said, Squad are updating to Unity 5, which is known to have a better PhysX, will make use of multiple cores and will be faster, how much faster we don't know yet, estimations run from 10% to 50%, and Unity 5 will eventually be able to take in c# code and convert it to c++, giving another speed increase, which will be on top of all the existing optimizations Squad has already implemented in KSP which you guys don't see, from the terrain to vessel loading to textures to improved build times, letting the devs spend less time waiting for KSP to compile and more time developing.

Regardless if you do or do not experience this problem (or take the time in your save to notice this problem) the fact that this thread has generated over 1400 views in under 4 day should signal to the dev team that this is an issue with which a not insignificant portion of the community is struggling with. To be honest at this point a lack of response on this topic from the team would be in my view, a very serious failure on their part.

Now, a lot of threads get a lot of attention in their first few days, this doesn't mean Squad should publicly acknowledge my little pony or the pronunciation threads we're currently seeing, and as well, many members have posted in this thread to say they don't have an issue, so they count against the 1400 views.

But lets say they do answer, what could they say?

They could say "Unity stutters and it's not the game", but I don't think that's what you want to hear and it'd take time away from actually developing KSP to say, in essence, "This is an engine issue".

They could say "We're moving KSP to Unity 5", which they have said already and would improve performance, but of course this isn't a fix right now.

Either way it adds nothing we don't already know, to an issue that is known to be Unity's, that we all know from many previous threads like this one that there's no workaround that is 100% for every player, there's no modding this away, and there's only so many sawtooth GC pictures (thanks sarbian!) you can look at before you say "hold on, what if we're on the wrong track here?".

You're not going to like any response you get, other than a "We're dropping everything to make a 1.0.5", but there isn't a fix, Squad cannot make KSP not use fixedUpdate as the physics are a fundamental part of the game, Squad cannot hack Unity to control the GC as that'd breach the Unity license, it's already called in quite periods nor do I believe it would have any effect at all.

And Squad cannot hack KSP to make the physics update match up to your visual update any further than providing a delta time slider, frame limiter and v-sync options, which they have done already.

The stutter sucks, I've seen it in youtube vids, support threads, and on my own game in the past, though thankfully not recently, Squad knows it happens and has already done all they can in Unity 4, and Squad is already doing more in Unity 5, that's all we can ask of them, not demand, not attack, ask.

This thread is going absolutely nowhere, people have already brought this issue up, efforts have already been made to make KSP smoother and those efforts are continuing despite what you may personally believe, there's been no failure by Squad in dealing with this, just a failure in some members patience.

If you want to discuss this issue you'll do so constructively, not with the disrespectful tone you've used here.

Edited July 24, 2015 by sal_vager

[steve_v]

Locked, then unlocked again minutes later? How peculiar. Nevermind.

That's an interesting alternative theory, and the first I have heard of it.

My focus on the GC stems from two things:

The frame delay/stutter matches the spikes generate by GCMon perfectly... your comment on "free time" would explain this perhaps..

Breaking the garbage collector, by recompiling Unitys mono fork with 'enablethreadedmark' vastly improves the problem.

It's also possible that this is in fact more than one issue, no?

- - - Updated - - -

Apologies if I offended you. This is extremely frustrating, particularly as it seems there's nothing I can do about it.

Edited July 24, 2015 by steve_v

[DuoDex]

I've said it before, albeit not with these words : There is a major engine upgrade in the works. Don't get too hopped up about something that might change in just a couple months.

[sal_vager]

That's why we have a team...

It'd be interesting to know what else 'enablethreadedmark' affects than just the garbage collector, and as I said, at these spikes, or just after, there's a nice little lull where the GC can catch up, as far as I know no one has proved it's excess untracked objects yet, I have not seen an explanation of what they might be, and GC activity is usually indicative of a leak.

Only Ferram has put forth an actual theory on how to reduce this, by reusing objects and variables you can avoid garbage collection, but this is untested, and could mean KSP uses even more RAM.

Some threads I have seen mention that rigidbodies are themselves expensive to create and destroy, but Unity doesn't provide much control over that, with many undocumented features still in the engine it's hard to know if you've overlooked a method to reduce that cost.

And Steve, yes, it's very frustrating, nothing I've tried suggesting in all the time this issue has existed has worked.

[steve_v]

If I'm reading it right, that option enables an (experimental) multithreaded version of the "mark objects as collectable/unused" pass. It's commented (presumably by Unity, as it works fine in stock mono) as "causes crashes", which indeed it does... because the GC never runs when it's enabled.

If one ignores the expected fire-hose like memory leak, this does significantly reduce the length of the pauses.

Unity has made many changes to the GC code in the fork, and I haven't been able to get to the bottom of why it's broken here, let alone test with the even more experimental sgen GC code - which again works fine in stock mono.

I've mucked with pretty much everything I can get at, and it's the only thing that makes a difference...

But it doesn't eliminate the stutter completely, so it may well be as you say - the GC is just taking advantage of idle time while something else holds up the pipeline.

[sal_vager]

Something makes the GC think it's time to shine.

But if the GC doesn't run with it enabled, and it still pauses even if only a little, then the GC would be a contributing factor rather than a cause and is probably running when it shouldn't.

But what I want to know is what is all that stuff in memory?

Edit:

The GC would be exacerbating the issue by lengthening the pause, not necessarily contributing to the cause of the issue itself.

Edited July 24, 2015 by sal_vager

[steve_v]

You and me both, but my lack of access to the source and general lack of experience with Unity (or managed environments in general) really leaves me at a dead end here

I've done plenty of playing about with open source projects - mostly native C, but apart from KSP I've had nothing to do with .NET/mono/C# etc. So I'm not entirely sure where to start with finding out what "all that stuff in memory" actually is... Is there even a way to examine the heap in realtime?

[sal_vager]

Not in realtime I think, only by stopping the program but not allowing it to clear the RAM, a memory snapshot if you will, there's probably lots of tools do do this and as it's in your RAM it's not decompiling.

[steve_v]

Hmm, sounds... time consuming. I can certainly do this with native code, but without debugging symbols etc. it might be a little difficult to see what's going on - assuming a memory dump of monos process will actually resemble the contents of it's internal heap that is. I have my doubts.

Surely Unity must provide a way to do this, but I don't have Winblows, so I don't have Unity... Argh. I might find a chance to play with this, but I suspect I'd be wasting my time.

[DMagic]

Something makes the GC think it's time to shine.

But if the GC doesn't run with it enabled, and it still pauses even if only a little, then the GC would be a contributing factor rather than a cause and is probably running when it shouldn't.

But what I want to know is what is all that stuff in memory?

A significant amount of it is probably coming from the UI. Without careful consideration of what your UI is using you can end up with lots of objects being created for every GUI frame. This is one of the things that I've been continually looking at in my addons because it's such an issue.

It's one of those things that is totally independent of what else is going, how big your craft is, how many active vessels you have, etc..., it just always runs. But, of course, there are probably numerous instances of objects getting created and dumped while the universe continually updates.

[sal_vager]

Thankfully the UI is being rewritten, it'll look the same and do the same things but Unity 4 had a couple of different methods, Unity 5 has a unified UI backend.

[rkman]

Now, a lot of threads get a lot of attention in their first few days, this doesn't mean Squad should publicly acknowledge my little pony or the pronunciation threads we're currently seeing

Right, but this is not one of those threads is it?

[steve_v]

A significant amount of it is probably coming from the UI...

This meshes with what I've seen regarding the impact of certain mods - having a UI onscreen has an unexpectedly large impact on the frequency of GC runs, even when said UI isn't actually doing anything.

One does wonder why Unitys UI system is so horribly inefficient - surely a static element doesn't need to be repainted every frame - but it sure looks like this is what's happening.

Hopefully the U5 update fixes this, along with the necessarily ugliness of the UI in general...

I haven't touched it myself, but from what I've heard it's not exactly nice to work with either.

Edited July 25, 2015 by steve_v

[TMS]

Hopefully the U5 update fixes this, along with the necessarily ugliness of the UI in general...

Brace yourself...

Apparently, they're putting a lot of effort into making the new U5 GUI look exactly like the dog ugly existing one.

On the plus side... Maybe it'll be easier to mod???

[steve_v]

making the new U5 GUI look exactly like the dog ugly existing one.

Rats. I guess I'll stick to hoping for more efficiency, but consider my optimism shaken.

[DMagic]

One does wonder why Unitys UI system is so horribly inefficient - surely a static element doesn't need to be repainted every frame - but it sure looks like this is what's happening.

Somewhere a Unity dev is maniacally laughing at this. The "answer" is that the legacy Unity UI really isn't meant for rendering things in-game, it's more suited for pause menus and things like that which aren't displayed all of the time.

There are a few elements of the UI that can really bog things down if not handled carefully.

For one, every single UI element, each button, label, slider bar, text box, etc... produces multiple draw calls to the GPU. And depending on how careful you are, all of these elements are being drawn whether or not you can see them. Take a scroll window with 100 elements that only shows 10 at a time. This will still render all 100 of those elements, even though most aren't visible. A few windows with elements like that can slow things to a crawl.

Another is that the system just lends itself to careless creation of new objects rather than reusing old ones. For instance, when the big map for SCANsat is drawing it takes one of the main texture and determines the color for each pixel, it stores these colors in a single array. It used to create and destroy this color array one every GUI frame, so you would have something that is potentially several kb (for a 1000 pixel wide map, that's a 1000 element color array, with each element using 16 bytes, that comes out to 16kb) being created and destroyed several hundred times whenever you refresh the map. I fixed that, and several other similar objects, so that it just initializes the array once then reuses it. Now just imagine a dozen other UI windows doing something similar on every GUI frame and it's easy to see where the waste comes from.

The new UI uses separate Unity game objects for each element, which just lends itself to better object handling than the old system (though it's obviously still possible to be careless and wasteful).

[basic.syntax]

Bolstering DMagic's words, this quote from Mu on the May 30 SQ:

Mu: "We're eliminating all uses of OnGUI from the code, which is.. if you've profiled the game, it's a huge black pit of performance..

[steve_v]

Good news indeed. Honestly, the more I learn about how Unity works the more horrified I am.

[maceemiller]

I have the stutter on my game, however it doesn't affect my enjoyment one little bit! For all the little bits'n'bobs that may not be 100% working correctly there is plenty that is. I for one am not bothered about the stutter.

Edited July 27, 2015 by maceemiller

[SessoSaidSo]

I have the stutter on my game, however it doesn't affect my enjoyment one little bit! For all the little bits'n'bobs that may not be 100% working correctly there is plenty that is. I for one am not bothered about the stutter.

So you are unconcerned with a bug you notice and the devs will not fix and are happily content because "hey other stuff does work"? Wow. Just wow.

[pxi]

I think we all want this fixed, however not all of us are in the "FIX THIS LEIK YESTERDAY!!1!" camp.