• 8
SessoSaidSo

It's been 6 months since I asked about the stutter

Question

Hi.

So back in July I was pretty upset about the stutter or micro freezing as it may be known. Now it's been pretty much concluded it is due to the GC of Unity 4.x, and I have been playing 1.0.5 and see it is worse than ever.

For reference I play off a custom rig running:

Windows 10 Home

i7-5820k

GTX 980 Ti

16 GB DDR4

I generally use a resolution of 2160p or 1440p

I have run the game from the following 3 drives:

SM951 256 m.2 SSD

850 Pro 256 SATA SSD

840 EVO 512 SATA SSD

I go back and forth playing the game with DirectX and OpenGL. Problem persists either way, so I generally stick to OpenGL for performance reasons(RAM savings are significant).

No. I do not spend all my money on computer parts. I work for a large IT vendor. 

I believe back in July I came off as a Kerb-Hole, for which I apologize. I am interested in understanding if the GC issue is a currently acknowledged issue from Squad and if the team is aware of its presence (or lack thereof) in Unity 5.x. 

 

TL;DR...too bad. Go Back up and read it.

Share this post


Link to post
Share on other sites

Recommended Posts

  • 0

@SessoSaidSo I take it you are referring to this thread? If so, I am also waiting for some news. It's been a long time now with no improvement. :mad:

4 hours ago, Waxing_Kibbous said:

 think the well described phenomenon you are referring to is called "animation."

I think you are wrong. Go read the thread I just linked, and try one of the easy tests mentioned there.

-----

6 hours ago, CliftonM said:

I'd expect some of this to be fixed in unity 5.

If this is, as I suspect, caused by the brain-dead GC code in the ancient version of mono that Unity uses... that has not changed in U5.

If it's the GC at fault (and I'm pretty sure it is), the only solution short of unity upgrading their mono runtime is to create less garbage. This is something Squad could, and should be doing.

Edited by steve_v

Share this post


Link to post
Share on other sites
  • 0

Demo Unity4 projects also show this stutter albeit less severe as they have fewer game objects, so it's not garbage as actually freeing unused resources is very fast, you just call free() on it and move on.

What makes the Unity version of Monos GC slow is that it walks the entire memory heap looking for something to free, so the more objects you have the longer it takes.

Look it up if you like here, here, here and here.

It does this automatically and periodically when free space is low, there is no off switch.

So it's not a case of too much garbage, or in fact any garbage, if you actually watch KSP's memory use while it's running it's not fluctuating that much, there's not much that isn't in use for the GC to remove.

When you have a lot of objects the Boehm–Demers–Weiser garbage collector used by Mono is slow, whether there is anything to free or not it's still going to walk the stack looking for objects to free.

So any attempts to reduce garbage by Squad would have no little effect on the stutter, Squad has already optimized several parts of KSP.

 

As for Unity5, there are benchmarks from other software available to make comparisons, and the inclusion of a newer PhysX should might mean that  physics can continue on another core while the GC is collecting, preventing it from blocking the simulation (ie the stutter)

But we won't know until KSP 1.1 is released, or until performance is discussed in the devnotes, so keep an eye on the devnotes for news :)

 

Edited based on Padishars comments, added stuff is in italics.

Share this post


Link to post
Share on other sites
  • 0
18 minutes ago, sal_vager said:

What makes the Unity version of Monos GC slow is that it walks the entire memory heap looking for something to free.

This gells with my own experimental tinkering with Unitys mono build - the 'mark' (heap crawl) phase is the main culprit. Giving it something to collect does however exacerbate the problem.
The properly frustrating thing is that this has been much improved in upstream mono, and quite some time ago. Unfortunately Unitys build has diverged too far to backport those features, or drop in a more recent runtime.

As usual, commercial entity forks open-source code for their own purposes, and promptly makes it incompatible with and inferior to the original project.

Edited by steve_v

Share this post


Link to post
Share on other sites
  • 0
4 minutes ago, sal_vager said:

Absolutely, and I hear Unity won't upgrade Mono any further, but the replacement also uses the Boehm–Demers–Weiser garbage collector (libgc).

This is not what I wanted to hear, but they do mention improvements to the GC problem, so... maybe some optimism?

6 minutes ago, sal_vager said:

Ouch, we all know what happens if you use that. :P

Share this post


Link to post
Share on other sites
  • 0

The 3rd point is optimistic because I'm being optimistic over Unity5's performance, I'd rather do that than be pessimistic, I'm hoping for the best.

As to the second point, please show me where KSP is allocating and removing 1000 objects on every frame as I find that unlikely, you make it sound like KSP is making and removing 1000 Kerbals or 1000 GUI's, which would have a much larger impact than we actually see.

Unless you mean it's updating 1000 objects, which it may be doing with the PQS terrain but also seems a rather high number, and creating temporary variables which are automatically removed when those functions go out of scope is normal, but other objects in use aren't garbage and won't be freed.

Thinking about it for a minute doesn't lead me to your conclusion, sorry.

As for the first, the stutter is pretty regular, thats periodic enough for me.

Share this post


Link to post
Share on other sites
  • 0
16 minutes ago, sal_vager said:

Thinking about it for a minute doesn't lead me to your conclusion, sorry.

Perhaps not, but the obvious change in GC frequency when there is much garbage being generated might. Example.
This is also an example of Squads code rapidly generating garbage, and reducing such would certainly improve matters, if only in this specific case.

16 minutes ago, sal_vager said:

As for the first, the stutter is pretty regular, thats periodic enough for me.

Casual observation does not data make. :P

Also, as Padishar points out, this has nothing to do with PhysX. GC not interrupting the physics thread is irrelevant if no managed code can allocate memory - everything else will still have to stop.

Edited by steve_v

Share this post


Link to post
Share on other sites
  • 0

I'd have chosen a better example that that, he is after all using 80 fuel cells, that's a lot, it doesn't matter what game it is you're going to reach its limits at some point unless it caps you, such as the unit limits in RTS games.

Fact is I don't know what is going on inside KSP, I don't know if it's Squad code or Unity that is causing this, and I don't know if Squad has already added free() to their objects to remove them and it's being deferred by Unity.

Only the developers could tell us that.

I also don't know if the GC can run at the same time as PhysX, which is why I said "should" not "will", we'll all have to wait and see just how things improve if at all.

I expect that performance be better for some, same for others and there's the chance it'll be worse for a few, there's just too much variation in players PC's to know how it'll be on any given computer.

But I hope it'll be improved.

Share this post


Link to post
Share on other sites
  • 0
2 minutes ago, sal_vager said:

I'd have chosen a better example that that, he is after all using 80 fuel cells, that's a lot, it doesn't matter what game it is you're going to reach its limits at some point unless it caps you, such as the unit limits in RTS games.

Well, the point of that was simply to show that the frequency of GC runs is not static. 80 fuel cells may be a lot, but extreme conditions make for an extreme change in GC behaviour, and therefore a clear example.

Share this post


Link to post
Share on other sites
  • 0

I'll ask if they can explain it to me, my programming knowledge is still at the beginners level especially when it comes to c#.

I'm not convinced that KSP is creating as much garbage as people think, lots of variables that are in use maybe, but not useless junk, I base this on just how little memory is actually freed when the GC runs, so I think reducing garbage is not going to help as much as reducing how much KSP demands from the engine, there's a lot happening which can't be offloaded to PhysX such as orbit calculations.

You're passionate on this subject, and passionate on KSP in general and I respect that, but I wonder if we've all been distracted by the idea that Squad must be generating tons of garbage when there's been several optimization passes to PQS, orbit prediction (see past devnotes)) and other areas of KSP yet the GC still runs.

Without knowing what is being collected by the GC it's impossible to claim it's one thing or another.

 

Edit:

I'll add that Unity does make and remove objects independently to the KSP code as well, I found in this thread that Unity keeps polling the attached controllers  to see if they are still present, which makes and removes a lot of variables every time.

Share this post


Link to post
Share on other sites
  • 0
1 hour ago, sal_vager said:

he is after all using 80 fuel cells, that's a lot, it doesn't matter what game it is you're going to reach its limits at some point unless it caps you, such as the unit limits in RTS games.

No, that's not a lot, and there's no excuse for a script as simple as that to furiously allocate garbage in every fixed-frame. 80 is far from a reasonable number for such CPU dropdown as well, but that's a direct consequence of GC's work and old resource code. There's definetly a fixing to be done.

Generally, SQUAD did a good job with purging new operators from scripts: on my machine GC runs approx once in 12-13 seconds, but every time I feel it, i see the jump, the micro-lag. And I can only envy those, who don't. Just another plague with no cure. C# itself is not helping, just look at those ToString() methods and general string immutability policy, what an abomination for realtime systems.

Share this post


Link to post
Share on other sites
  • 0
On 10/01/2016 at 6:49 PM, SessoSaidSo said:

I appreciate the productive comments. How can we get Squad to acknowledge this issue?

Sorry but I have to stop you there, Squad doesn't have to acknowledge this issue, just as they don't have to post official statements for any other issue in KSP.

But Squad has posted in the devnotes about performance increases, HarvesteR has posted about optimization on many subjects from PQS to orbit calculations, you're welcome to use the forums search box to locate these (it's fixed).

You seem to be trying, again, to get some kind of official apology or confession from Squad regarding the stutter, but I need to remind you:

All indications are that it is caused by the garbage collector, this is not Squad code and Squad cannot change the GC.

The Unity engine can easily be creating objects based on Squads use of built-in Unity commands, which then have to be collected, this is not Squads code and it can't be edited as it's closed source and the licensing forbids it.

Squad are really pushing Unity with the orbit physics, Unity isn't really designed for this but Squad are doing the best they can, but they will still run into limits with what Unity can do and how Unity functions, this is not something Squad can change directly so they are updating to Unity5, which offers more performance.

Squad can only fix their stuff, which they are doing and will continue to do, but to expect an acknowledgement is unrealistic, they should not be held accountable for code they cannot control.

The answer to the original question is "Wait for KSP 1.1 and find out".

Share this post


Link to post
Share on other sites
  • 0

Try running ksp on true fullscreen mode.

http://forum.kerbalspaceprogram.com/index.php?/topic/103537-ksp-10x-090-windows-true-exclusive-fullscreen-shadowplay-and-gsync-solution/

I gain around 20 fps on my i7 4700MQ @3.0GHz, GTX 770M, 8GB DDR3 RAM 1600MHz, 250 GB Samsung Evo SSD.

As a bonus I can record with shadowplay even on laptops and with even more negligible performance impact on my desktop, like if there was any.

Share this post


Link to post
Share on other sites
  • 0

I think your point about the fuel cell code has been adequatly made. There's a confirmed bug on the bugtracker about it as well. The situation comes down to the fact that there is a limited amount of development time available, even to fix bugs. We have to make choices, and although the microstutter is annoying it's not breaking the game in any meaningful way. We can spend a lot (and I mean a lot) of time to marginally improve the situation, but we cannot outright fix it. That leads me to conclude that there are plenty of other bugs, pieces of feedback and new features that we can spend that time on, and come to an overall more meaningful improvement of the player experience.

Coming back to the fuel cell issue in particular, I can see that the issue (this isn't even necessarily a bug) exists, but why would anyone activate 20 to 80 fuel cells on board a spacecraft? The actual impact of this issue is next to zero in the vast majority of use cases. I think we should also be careful to proclaim ones vision as that of the majority of players ("general concensus" and "a lot of people's eyes") given that even on these forums which are the biggest community website for KSP we'll find only a relatively small group of the people who own the game. And a small group within this relatively small group have the technical knowledge requiredd to identify, discuss and underline these issue, I would say you're definitely within this small group, but that does not mean you're speaking for a majority of the players as a whole.

Share this post


Link to post
Share on other sites
  • 0
16 minutes ago, Padishar said:

I would be surprised if the majority of the forum users don't agree with me...

Post a survey with the question, and you'll know.

Share this post


Link to post
Share on other sites
  • 0
1 hour ago, KasperVld said:

and although the microstutter is annoying it's not breaking the game in any meaningful way

What!? The stuttering has ruined the game for me! I can't play Kerbal Space Program, I can play Kerbal Space a-few-craft-at-a-time, but I can't actually get a space program with lots of craft in flight, sat networks, bases etc.  As soon as I really start to get into building a program the game becomes unplayable.  

And to backup what @Padisharsaid, In my opinion this and other performance issues are the only thing I care about being done to the game.  I want this fixed so badly I'd pay just to have the issue bumped! All other planned features and improvements to existing features are secondary in my view, ie; everyone notices the lack of a search on craft/parts lists and that's an obvious feature to add.  I'd like it, but I'd far rather this was sorted.....otherwise all the search adds is a more efficient way of getting me to where I experience the stuttering!

Spoiler

I still enjoy working on single craft, but previous versions have got me expecting more.  I once had a space program that spanned several KSP versions, had been going for... I don't even know how many kerbal years, had bases everywhere, sat networks, artifacts from failed missions etc. It had character, it's own history and lore simply because of how long it had been going.  The save file was 15mb, most of the craft were unnecessarily complex (easily 300+ parts) and heavily modded and the game ran fine (it would crash on some scene changes, but running performance was good).  

I have now just abandoned yet another save (with ~30 craft, just around Kerbin and Mun) because the stutter was becoming unbearable.  That save wasn't even a mb and due to other performance issues none of the craft were over 200 parts.  KSP is currently a shadow of it's former self and this issue and other performance issues are the cause of that.

Kasper, I don't think you are right in saying that there are other issues that are more important to address than this.  This is a foundation level issues that impacts on the entire game.  Other issues may be more apparent to the majority of users and therefore fixing them seems like the "value added" thing to do, but good agile/lean methodologies say that if you identify a foundation level problem you stop all other work and fix/mitigate it before carrying on. There's no point in building features on the back of a faulty foundation. 
Ok the foundations here aren't totally crumbling and for most people they'll hold up, but there are those of us who push them to breaking point (constantly) and while we may be aberrant members of the community we have identified a weakness that is load dependent.  If focus is made towards other fixes and new features, then that will result in an increased load being added to the existing problem and eventually it could become something that impacts on everyone.  At which point it will need addressing, and then so will everything else that sits on it, resulting in a greatly increased workload to solve the same issue.  

1 hour ago, KasperVld said:

We can spend a lot (and I mean a lot) of time to marginally improve the situation

This is the rule of 9 and is something to be expected as standard for development.  To take an existing feature from 70% done to 80% done will probably take the same man-hour commitment as taking it from 0% to 50%.  It's very easy at this stage to see the addition of new features (ie a craft/parts search) as being something that adds more because the same man-hour commitment will yield more apparent value added, but that is a trap resulting in something that is feature rich but lacks refinement and will have trouble scaling. 

 

This bug and the responses about it have left me feeling quite despondent about KSP's future as a game that I enjoy playing.  I've resigned to wait (mostly quietly) until the next version and see how things are then (at which point if the issue still exists I might end up earning a few forum warning points!).  

My big fear about this issue is that if the game's performance is improved (by other optimizations) but this issue remains, it will still eventually become apparent to those of us who build big (craft and overall program) but then it will be even harder to demonstrate it to anyone else and we'll have even less chance of getting it addressed. If the game's performance is so greatly improved by the other optimisations that it completely mitigates this issue then that would be great, but I don't think that's a realistic expectation. 

My hope for KSP once it's last update has been released is to have a space program that I can keep adding to, for years (RL) to come.  But if this issue remains, that is not something KSP will be capable of.

Share this post


Link to post
Share on other sites
  • 0
44 minutes ago, Padishar said:

Hehe, yeah, I did consider it, but forum surveys aren't exactly the most statistically sound source of information to be drawing firm conclusions from (as is pointed out in a lot of survey threads).

Not the most perfect method, agreed. But I'd think it's statistically a little more sound than 'probably' 'I'm pretty sure' or 'it would surprise me if'...

Share this post


Link to post
Share on other sites
  • 0
4 minutes ago, Padishar said:

By all means make a poll if you think that.  I'll vote but otherwise keep out of it because I can't be bothered with the validity argument that will probably ensue followed by locking of the thread...

I wasn't actually arguing for a survey. It was brought up to illustrate a point. I will leave it at that.

Share this post


Link to post
Share on other sites
  • 0

Hi,

I have to admit that the level of detail lost me already.. but taking my time to understand the given arguments, i REALLY have to take @Padishar side.

For me it's not about this specific issue he is adressing, but i really admit his style to speak about it, trying to give good feedback and ideas how to solve it.
Working as an IT-Speacialist I really would like all my customers to be this helpful with their comments.

On the other side the moderation seem more about trying to justify the situation instead of valuing the very detailed feedback about the technical issue and how it effects the customer.
It seems more like a "just because it bothers you is not enough for us" instead of a "hey, cool someone is really helpful here and building up a bridge to the community".
You cant know how many users are affected by this and just not speaking / adressing it or even know about the reason. So valuate everyone that tells you what is going wrong, especially in this manner here.
So my highest respect for @Padishar & @katateochi . I couldnt be so constructive even if i'd try.

 

The best reaction on feedback is (and has always been) to valuate it and not trying to legitimate the reason / ones behaviour.
If you CAN'T change it, say so.And Value the feedback anyways 
If you can change it, value the feedback even more and take it as a reason to give it higher priority.

You cant expect every player that suffers of a explicit bug to tell you about it - but you can expect that some powerusers are your very best source for bug-reports and so one of the best reasons to address them.

And by that you would take the opportunity to show the community, that even those bugs most cant identify / find a reason for, are already adressed and trying to be fixed.
As for now, i got more a feeling of "deal with it, we dont care" instead of a "hell thanks for bringing this up again, we are doing our very best" out of squads reaction.
And im pretty sure you will lose your most professional users & support in identifying bugs with this attitude!

Just think about the time someone puts in those posting to help SQUAD to improve their product. Not speaking about time he used to identify it and the time&anger he "lost" because of it. He doesnt earn money for all this, he volunteered to support you in making this game even better eventually bringing more money & better reputation to squad - not to him.

Just trying to justyify this might be almost as negative as ignoring it.

Edited by Speadge
highlighting

Share this post


Link to post
Share on other sites
  • 0

Constantly experiencing this issue, I also agree with most of what has been said on it, concerning the level of annoyance.

I started playing KSP in every major update only to be turned away by the epic stutter when getting to a point where it was becoming fun. I admit to modding the crap out of the game but from reading up on the microstutter it is bound to happen in stock games at a certain point, anyways.

I also agree that there is little on-point response to the issue, seeing as most threads on stutter are derailed by people asking for logs / relating it to hardware etc.

Personally, it cost me a lot of time trying and making the game stutter-free. I spent the last week setting up a dual-boot debian, adding and removing mods for optimal performance and fiddling with every setting imaginable that could affect performance, because the majority of threads on the stuttering did not refer to the engine having this issue but rather it having to do with personal setups. Playtime-to-fiddle-ratio is probably around 20:80 :(

I acknowledge, however, that in addition to the issue manifesting itself differently for everyone, its severity also seems to depend on individual perception.

Edited by skYman
corrections

Share this post


Link to post
Share on other sites
  • 0
8 hours ago, Padishar said:

The issue I have described with the GetConnectedResources function is not specific to fuel cells, they just provide a particularly good example because they call it 6 times every physics update.  Every running engine and thrusting RCS block also calls it on every frame (though rocket engines use a flow mode for which it should run much quicker).  The resource window also calls it for every resource.  The RCS blocks can cause issues when docking large vessels as, while you are pressing an RCS key (or SAS is pressing it for you) each RCS block that fires calls it every frame.  This can be a considerable number on large vessels, easily enough to significantly affect the frame rate (and greatly increase the frequency of GC), which you really don't want when trying to make accurate control inputs for docking.

Very well put.

I was going to argue something similar:

Fuel Cells are the best for showing the impact of this issue, because they don't produce exhaust plumes or other graphical effects, that can disguise the cause of framerate drops and stutters.

Share this post


Link to post
Share on other sites
  • 0

I have just bought this game at full price on steam as I was really looking forward to playing it. It was all running fine at the start but it has got progressively worse.  It was a slight annoyance at first and I could cope with it freezing for 1 second every 30 - 60 seconds, but I have just loaded it up from earlier today and the problem has amplified to the point I am getting too peeved off to keep going. I feel quite cheated I have to admit paying £30 for a full release game with such dire performance issues. Which has brought me here to find out it is known problem for the last few years. I have read all of these comments to find that there is no real conclusion other than wait and hope for the best.

What are the consumer rights for a product that does not work properly, I understand that buying an early access game on steam is a risk and you have to just accept performance issues, but this is a full release at full triple A price and it has practically become unplayable. I have put in 95 hours so far and it has just broke. I was so addicted to the career mode :). I wanted to do this first before I bothered with any mods. 

I will leave this post here and offer sympathy to all players it has affected, and also to keep me updated via email with your input. Hopefully it can get resolved soon with all the extra development funds they must be generating from the full release. I love this game and would hate to see this problem persist over future updates.

Thanks for all the input, I will check back soon :)

Share this post


Link to post
Share on other sites
This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.