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

[sal_vager]

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.

[Boris-Barboris]

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.

[Padishar]

Every time the code needs to know how much resource of a particular type is available (or how much space is available) it creates a new List object (which also allocates its internal array usually with the default initial capacity of 4) and scans through the whole vessel adding each Part's sub-objects that represent that resource in the part to the list.  This should only be adding the references to the list but the PartResourceList.GetAll function (called from Part.GetConnectedResources) itself creates a new List object and adds all of its resource storage sub-objects that are the correct resource type to it before returning the new List.  GetConnectedResources then copies the items from that list that have flow turned on into the one it is building and discards the list returned from GetAll.  Also, when a List object becomes full it allocates a new underlying array with twice the capacity, copies the contents across and discards the original array.  Once the list is built, it is scanned to calculate the total or space or to add or remove resource from the parts.  Then the list object is discarded. So, as well as the main list (which is at least 2 "objects" in the heap), there is also another list for every part that has storage for the resource.

Edit: Actually it is much worse than this.  The PartResourceList.GetAll function is called on every part and always creates a new list even if the part doesn't have any resources at all.  This means that every call to GetConnectedResources actually creates at least 2n + 2 bits of garbage where n is the part count of the vessel.

On every physics frame the ResourceConverter code for a fuel cell first checks to see if the source resources are available (it does the above for each source resource). Then it checks if there is enough space for the output resource (another of the above).  Then it actually removes the resource from the source parts but runs the above code again rather than reusing the lists from before (two more runs of the above code) and then it adds the resource to the output parts (another call of the above).  That's six calls every frame to a function that creates quite a lot of pointless garbage.

KSP does create a lot of garbage.  The slope of the GCMonitor graph is a direct display of how much.  Strictly speaking, the slope is the rate of memory allocation but, since the graph drops down again when the GC runs the memory must have been "released".

Edit: For a 50 part vessel with two active fuel cells there will be at least 2 * 6 * 102 = 1224 bits of garbage created just by the fuel cells on every physics frame.  The example in the bug report of a 75 part vessel with 72 fuel cells creates 72 * 6 * 152 = 65664 bits of garbage on every frame.

Reducing garbage creation is the only thing that can possibly stop (or significantly reduce the frequency of) GC stutters.  Ideally, the GCMonitor graph would generally be a horizontal line during scenes with steps up when things need to allocate memory from time to time (e.g. when another vessel comes into range, you change SOI or such like), but they certainly shouldn't be allocating any memory and throwing it away again on each frame (or multiple times per frame).

Edited January 12, 2016 by Padishar

[anarkhon]

On 2016. 01. 09. at 3:43 PM, Speadge said:

please dont quote _whole_ posts that are so long..

To your comment: is there any source where u learned that? Im running fine with <4> on this setting.

Lot of reference,just google it.i do the kick you have to research it.

http://forums.anandtech.com/showthread.php?t=2322148
 

[SessoSaidSo]

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

[sal_vager]

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".

[tetryds]

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.

[Padishar]

I actually thought you'd locked this thread or I would have replied sooner.

On 1/10/2016 at 9:02 PM, sal_vager said:

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.

Yes, this is true.  However, they also don't have to hide behind inaccurate replies posted by their staff.

On 1/10/2016 at 9:02 PM, sal_vager said:

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).

Again, yes, there have been various optimisations to various parts of the game.  However, the generally accepted consensus is that the overall performance of the game is getting worse with each update, not better, so there is still plenty of room for improvement (and for constructive criticism).

On 1/10/2016 at 9:02 PM, sal_vager said:

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

Yes, it is caused by the garbage collector.  However, I thought I had explained that changing the GC is not the only way to improve matters, reducing the amount of garbage created will reduce the frequency of the stutters regardless of what GC code Mono/Unity uses.

It is true that not all of the garbage that is created is done so by KSP code (rather than Unity) and, some aspects of how C# works makes it virtually impossible to eliminate all garbage (most notably that string objects are immutable, code that modifies a string always creates a new object) but some of the code in KSP is so bad in this respect that fixing it must reduce the frequency of the stutters and improve the performance of the game in general.

I also edited my post above to say this but I'll say it again here.  Each fuel cell creates over 12n bits of garbage on every physics frame where n is the total part count of the vessel.  For a 50 part vessel with two fuel cells that is over 1200 per frame, over 30000 per second.  For a 250 part vessel with 20 fuel cells the number would be over 60000 per frame, over 1.5 million per second (if your computer could keep up with 25 physics updates per second with that amount of garbage thrash happening).

This particular bit of code could be vastly improved by some simple refactoring (mostly passing the list to be filled in to the PartResourceList.GetAll function).  This would eliminate the list that is created for each part removing almost all of the garbage creation.  This would make a significant difference even without the other optimisations that the ResourceConverter code is crying out for.

On 1/10/2016 at 9:02 PM, sal_vager said:

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.

Well, Squad certainly are accountable for the fuel cell code.  Giving an acknowledgement that this code (and numerous other areas) produces excessive garbage (or uses a highly inefficient algorithm etc) and is contributing to the stutter (or general poor performance) would not harm Squad's image and would probably improve it in a lot of peoples' eyes.

[KasperVld]

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.

[Padishar]

13 minutes ago, KasperVld said:

I think your point about the fuel cell code has been adequatly made.

So why is a Squad staff member still claiming that KSP doesn't produce much garbage?

12 minutes ago, KasperVld said:

and come to an overall more meaningful improvement of the player experience

In whose opinion?  Calling it "microstutter" makes it sound like a minor issue but the people that suffer badly with this issue find the game virtually (or even actually) unplayable. Would you play the game if it paused for half a second every 2 seconds?  I certainly wouldn't.  I imagine they would much rather this was fixed (or at least improved) than any new feature being developed.

16 minutes ago, KasperVld said:

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 have seen numerous vessels posted in this forum that are close to or exceed the 250 parts with 20 cells example I gave above.  Even a single fuel cell on a large vessel will cause a lot of (totally pointless) garbage to be created.  In any case, you are missing the real point in all this.  If there is one bit of code that is this rampant with garbage creation (and general inefficiency) then there are almost certainly many others.

19 minutes ago, KasperVld said:

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.

I was careful.  The "generally accepted consensus" part was talking about performance and I have absolutely no doubt that the game runs measurably slower using the same (fairly large) vessel (as same as it can possibly be given the changes in the game) in 1.0.5 than it did in earlier versions and I have seen far more people posting this observation than the opposite.  I have a vessel (somewhere, I'll try to dig it out) that gets just over 10 fps in 0.25 but can barely manage 3 fps in 1.0.5 (and, yes, all the game settings are set to be as similar as possible and even if 1.0.5 is given a boost by tweaking the settings it never gets over 4 fps).  Yes, it is quite an extreme vessel but I didn't deliberately design it to show up this performance difference, it just does.

As for, "in a lot of people's eyes", again, I think I'm on pretty solid ground here.  I wasn't speaking for everybody, if I was then I wouldn't have said "probably" and would have said "all" instead of "a lot".  I reckon I could probably find (at least) a couple of hundred members of this forum that would think better of Squad if they did this and, while this isn't a lot compared to the total user base, I believe it can still be described as "a lot".  Admitting your faults is a much nicer trait than pretending they don't exist and, where paying customers are concerned, it makes a much better impression to acknowledge faults even if you also say you can't work on them yet rather than your staff trying to brush it under the carpet with misleading (or just plain wrong) statements.

Also, you make the point that the forum is only a small proportion of the user base (which is true) but if this acknowledgement were made in the forum then only the forum users would see it.  I didn't use the word majority but, given the general maturity level of this community I would be surprised if the majority of the forum users don't agree with me...

[swjr-swis]

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.

[Padishar]

49 minutes ago, swjr-swis said:

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

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).

[katateochi]

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.

[swjr-swis]

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'...

[Padishar]

14 minutes ago, swjr-swis said:

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'...

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...

[swjr-swis]

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.

[Speadge]

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 January 12, 2016 by Speadge
highlighting

[steve_v]

@Padishar I find myself agreeing wholeheartedly with everything you have said so far, and you do so far more articulately than I could.

48 minutes ago, Speadge said:

So my highest respect for @padishar.

Likewise

While I have relatively little experience with C#, I am not entirely unfamiliar with programming in other languages. What solid data we have points squarely at Padishars explanation being the correct one. In absence of any competing theories I can only conclude that the staff response is either uninformed or deliberately evasive.

I am trying to keep my cool here, I really am. But concrete statements like this:

On 10/01/2016 at 2:17 AM, sal_vager said:

So it's not a case of too much garbage

From a position of some authority, shortly followed an admission that you don't actually know:

On 10/01/2016 at 4:17 AM, sal_vager said:

Fact is I don't know what is going on inside KSP

Are not improving this situation.

Don't get me wrong, this is not a personal attack, and I don't know exactly how the code works either. But I'm getting the distinct impression that someone is trying to brush this under the rug. Something like: "I don't know what the issue is, but I'm sure it will be fixed some day, problem solved"
Please, tell me I am wrong about this.

 

4 hours ago, KasperVld said:

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.

Indeed, time is a limited resource. However, I for one would not describe this particular issue as "annoying". It's infuriating, and it seriously impacts the playability of the game. A 1/4 to 1/2 second stall is not "microstutter", it's "I can't enjoy playing because the game keeps freezing."
While there's no need for it to go straight to the top of the list, at present it doesn't appear to be getting any attention at all. Can you point me at any recent information to the contrary?

4 hours ago, KasperVld said:

...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.

To be quite honest, I'm not looking for a "meaningful improvement of the player experience", what I'm after is a playable experience, period.

 

I will of course wait and see if this is improved in the upcoming release, however the responses gathered in this thread leave me with precious little optimism.

At this point, count me in to the "this and other performance issues are the only thing I care about being done to the game" camp.

 

14 hours ago, Padishar said:

I actually thought you'd locked this thread or I would have replied sooner.

He did. I left in disgust at that point.

 

----

Now, would anybody in the know like to explain this issue and what is being done about it?

Edited January 12, 2016 by steve_v

[skYman]

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 January 12, 2016 by skYman
corrections

[Boris-Barboris]

I have a dream. Open-source KSP with protective licensing and semi-community semi-SQUAD controlled voting to apply merges. A man can dream, I guess...

[Padishar]

Also,

8 hours ago, KasperVld said:

There's a confirmed bug on the bugtracker about it as well.

Yes, I'm fully aware of that, I was the one who confirmed it (and take a look at the linked issues too).  However, a bug being confirmed on the tracker says absolutely nothing about whether Squad are even thinking about doing anything about it.

9 hours ago, KasperVld said:

Coming back to the fuel cell issue in particular...

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.

6 hours ago, swjr-swis said:

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

Could you explain what point you think it illustrates?  I may be being dense, but I really don't get what you mean...

 

[Val]

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.

[Padishar]

There is another issue with the Part.GetConnectedResources function.  It calls the PartResourceList.GetAll function presumably so it can handle parts that contain multiple "tanks" of the same resource correctly.  However, the Part.RequestResource functions (and various other code that does things with resources) simply uses PartResourceList.Get which only returns the first "tank" of the correct type.  This will mean that if someone creates such a part then the resource will show up as available in the main resource dialog (and the engine fuel gauges on the staging icons) but the contents of the extra "tanks" will not actually be available (except to resource converters because they use GetConnectedResources).

I've no idea if anyone has ever tried to make such a part, presumably someone at Squad has or, at least, they wanted to allow the possibility, or the GetAll function would never have been written in the first place.

Obviously, this shouldn't be fixed by changing RequestResource to call GetAll in its current form as that would give the GC a heart attack...

Edit: The Unity documentation goes into some detail about how the memory allocation works, common pitfalls to avoid and ways of working around them.  This page should be made compulsory reading for anyone writing code for Unity...

http://docs.unity3d.com/Manual/UnderstandingAutomaticMemoryManagement.html

Edited January 14, 2016 by Padishar

[Keenbop]

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

[Boris-Barboris]

del, sry

Edited January 15, 2016 by Boris-Barboris