[1.2.x/1.3] MemGraph 1.1.0.3 - with Stutter Reduction

[Padishar]

11 hours ago, Otis said:

I had noticed over time that the more on rails flights that I had, the worse my game performed, but I never would have suspected on-rails flights were causing garbage collection problems. I'm really excited now that this information has been brought to light.

Indeed, I expected some garbage due to on-rails vessels but I thought it would be proportional to number of vessels, not their part count.  This has been discussed with a couple of the Squad devs and a fix will, hopefully, be included in 1.1.3.

11 hours ago, Otis said:

Padishar, thank you for creating this tool. I feel it's only a matter of time now that we can all start seeing major benefits from this. This thread deserves a sticky and should be required reading for all KSP developers moving forward, IMO.

You're welcome.  As well as the padding mechanism giving some direct benefit to players with the current version, it is also helping to locate the worst offenders at creating garbage which should allow Squad to improve things more quickly and effectively than them having to do all the investigation work themselves.

9 hours ago, Wiseman said:

I was curious, though, if you know what's causing this behavior:

I was going to ask if you had tried anything similar in a stock-ish install but...

9 hours ago, Wiseman said:

Update: I think this has to do with Kopernicus, OPM, and/or the OPM visual overhaul mod, or some combination thereof. The framerate gets cranky every time I scroll in or out from a particular body, but that seems in line with my thinking as it coincides with the loading/unloading of those bodies. However, anytime I'm focused on a planet with rings, the memory usage and resultant garbage collection shoots through the roof. In any case, this seems unlikely to have anything to do with your mod, so my apologies!

No worries, your analysis sounds reasonable.  This is exactly the sort of situation that MemGraph helps locate.  It is probably worthwhile you testing with the visual overhaul part disabled/removed (assuming it still works like that) and then reporting your findings in the relevant thread (probably OPM as I wouldn't expect Kopernicus itself to be the cause, I assume the ring stuff is added by OPM).  In fact, I seem to recall a nasty lag issue being reported a little while ago though I'm not sure if it specifically mentioned map view.  In any case, the mod devs are likely to be grateful for any information you can provide about the issue...

One other thing, it looks like your heap is at over 3GB but you are getting GC after less than 100MB is allocated so there appears to be very little normal headroom being maintained by Unity.  Are you running low on physical memory?  What is the overall "Commit size" of KSP?

4 hours ago, Tig said:

PS.  To all other users, I'll say this a bit stronger than the mod author, this mod is in no way for people with 4GB of ram, and frankly be careful with your MemGraph settings with 8GB of ram if you're running stock.  Mods will run you out of 8GB of ram very quickly in my experience with MemGraph and GCMonitor.  I'm seeing my total ram usage (not heap) grow even in stock with every scene change still and mods exacerbate that issue, at least for me.  The moment you run out of physical ram by using this mod, which I've tested, you'll see a big drop in performance even on an ssd.  (I have a Samsung EVO, maybe the swap on an m.2 would be fast enough, i don't know, but I'll take donations towards buying one for testing purposes. )

Very much this ^^^.  There are still issues that cause the total memory usage of KSP to grow over time and you will still get memory problems with the x64 version, they'll just happen when you run low on physical RAM rather than 32bit address space.  Also, rather than crashing, in theory the game should continue running using virtual memory but the performance will take a serious dive and it may take your machine a little while to recover after closing KSP as all the other processes will have had their working sets seriously trimmed and cached file data will have been discarded to use the RAM for KSP so lots of extra disk access will be needed by other programs to load stuff back in.

4 hours ago, Galenmacil said:

I was going to write how I was unable to understand the new feature in MemGraph 1.0.7 until I finally figured it out. I used the "extra 0 at the end of each line" Padishar suggested and It seems to make a huge difference on the frequency of KSP garbage collection.

Edit: Reduced garbage collection frequency to 120s in between.

Glad you worked it out and that it seems to be working well.  Do you know what the GC interval was before you turned it on (and the total KSP commit size before and after)?

3 hours ago, Tig said:

For anyone confused by the numbers, my personal recommendation would be to double or triple @Padishar's numbers after the colon in padheap.cfg if you're running 16GB of ram.  Watch your ram usage with GCMonitor and adjust as you see fit.  I wouldn't change his numbers much with mods and 8GB of ram, but again the mods - how many/which ones - can have a profound effect.  There is NO one-size-fits-all settings with MemGraph to lessen with the stutter issue.   I'm just trying to give you a good starting point for anyone confused... hopefully it helps a few.

Again, great advice.  The default settings have been deliberately left low to provide a useful effect for any machine without increasing the memory usage by too much.  If people come up with good settings for particular setups then I'll be happy to add a link section to the OP (and/or host them on my dropbox).

3 hours ago, Tig said:

I wouldn't recommend just adding a zero to the end unless you're in @Galenmacil's range of 32GB+ ram.  ( hehe, saw your post before your edit   )

Indeed, as it should add around 9GB to the memory usage, it should only be done if you have significantly more than that free.  A stock install on a 16GB machine could probably get away with this (just about) but a reasonable mod load would end up very close to needing all the RAM in the machine.

[Gordon Dry]

I would like to test config settings and change them while already in game.

Is it possible that the mod can read the values of padheap.cfg when the window is toggled on?

[Padishar]

7 minutes ago, Gordon Dry said:

I would like to test config settings and change them while already in game.

Is it possible that the mod can read the values of padheap.cfg when the window is toggled on?

There's nothing stopping you, it reads padheap.cfg every time you hit the Mod-End shortcut...

Edit: though once you get settings you like the look of you should try them on a fresh start of KSP to ensure your previous tests haven't skewed the results...

Edited June 1, 2016 by Padishar

[Gordon Dry]

Okay, it didn't seem like that.

For testing I just removed (!) the last 0 and started the game, the intervals became too short, so I reverted the edit while in game but after a couple of hits and ALT+End the intervals were still short, not what I was used from yesterday. So I asked...

Now I halved the values and restart the game. (I got 16 GB and a bunch  of mods).

[Wiseman]

6 hours ago, Padishar said:

I was going to ask if you had tried anything similar in a stock-ish install but...

No worries, your analysis sounds reasonable.  This is exactly the sort of situation that MemGraph helps locate.  It is probably worthwhile you testing with the visual overhaul part disabled/removed (assuming it still works like that) and then reporting your findings in the relevant thread (probably OPM as I wouldn't expect Kopernicus itself to be the cause, I assume the ring stuff is added by OPM).  In fact, I seem to recall a nasty lag issue being reported a little while ago though I'm not sure if it specifically mentioned map view.  In any case, the mod devs are likely to be grateful for any information you can provide about the issue...

One other thing, it looks like your heap is at over 3GB but you are getting GC after less than 100MB is allocated so there appears to be very little normal headroom being maintained by Unity.  Are you running low on physical memory?  What is the overall "Commit size" of KSP?

So, since my first test and screens, I noted that my performance in Career mode is just terrible. I'm not sure what's causing it, but I did install GCMonitor to check on my commit size (although my Task Manager generally says I'm using around 6-8GB of my 16GB of RAM on KSP). New screenshot included below.

Spoiler

 The relatively flat and smooth parts at the end wrapping around to the beginning are me tinkering in the VAB. The spiky red bit is loading the flight scene, and the rest of the terribleness is just trying and failing to get this thing to orbit - no map view or anything else, just regular flight. This is with one Mod-End press and a tripled padding config. I feel like my results are being messed up by some combination of mods I'm using, so I'll have to narrow that down before my reports become useful.

Bonus fun:

Spoiler

The memory spikes only happen in career mode. To the right of the blue line is a test flight in career, and to the left is the in-progress sandbox flight of the same rocket. (the thicker red band about 2 minutes in is me going from the VAB to the flight scene.) 

Edited June 1, 2016 by Wiseman
Even more testing

[Padishar]

2 hours ago, Wiseman said:

I feel like my results are being messed up by some combination of mods I'm using, so I'll have to narrow that down before my reports become useful.

Well, your reports are already useful as they clearly show that something is being exceedingly rampant in its garbage creation (it might be interesting to try the same thing without the heap padding to see what the stutter is like then ).  Those peaks you are seeing, at what looks like a pretty regular interval, are often going out of the top of the graph, so more than 256 MB/s, which is just insane.  You have a lot of mods installed and there's a fair few I don't recognise from their toolbar buttons so it's tricky to suggest any likely culprits.  I would probably start by removing purely cosmetic mods and testing again.  Then, try without any mods that you can think of that might do things on a regular schedule (KAC, auto-backup, life support etc.).  It certainly shouldn't be anything to do with purely part based mods (unless they use stock KSP modules in really bad ways) so you can probably ignore most of those.

Edit: @Wiseman, for career only I guess the most likely thing is something contract related.  Do you have Contract Configurator and a shed load of contract packs?  If so, try removing that (or anything else you can think of that might be career only).  Also, probably worth doing a Science mode run too in case it is something to do with science experiments instead...

Edit 2: It's probably also worth testing a stock career game to see if that does anything similar.  It may be a stock career issue that is exacerbated by mods...

Edited June 1, 2016 by Padishar

[karamazovnew]

Absolutely amazing. My GC went from 8 seconds to 50 seconds. Thank you so much for this.

Edited June 1, 2016 by karamazovnew

[Padishar]

16 minutes ago, karamazovnew said:

Absolutely amazing. My GC went from 5 seconds to 30 seconds. I just doubled the values in the settings file (although I have 32gb available). Is it possible to make the mod so that it applies the mem buff automatically on game start?

Glad you like it.  It isn't currently possible to make it apply automatically though it should be quite easy to implement as an option (it needs to be an option at the moment for easier testing and comparison purposes).  Watch this space...

[Tig]

Hey Padishar,

I did find a correlation with those long lag spikes I'm sometimes experiencing.  Seems to be related to a high number of page faults.

From Process Explorer:

And a graph shot:

The red circles are mine.  Each one was accompanied by a long delay (10-20seconds) - sometimes in flight, sometimes on a scene transition, sometimes when purchasing a part in the VAB.

Memory goes from ~7.1-7.3GB and jumps up to 9.0-9.1GB.  On the first screenshot you can see a normal scene and then the huge page fault jump up to 16,000+ page faults.  Now process explorer doesn't differentiate between soft/hard faults (either that or i'm ignorant on how to make it do so ), but in any case my total ram usage never exceeds my 16GB physical ram.  So, I assume they are soft faults?  But then the I/O spikes as well...

But, not that much... the I/O spikes are about 50-60MB.  Kerbal and swap file are on ssd's... i can't imagine a 10+ second delay being caused by the swap on an ssd (Assuming that some are hard faults that need disk access in the first place).  The graph is about 50ish minutes.  So, its infrequent, and not consistent in occurrence.  Sometimes 30 min apart, sometimes 5 min.  The *only* time I can say with certainty its happened more than once is when I've purchased a part in the VAB.  2 times for sure, maybe 3.  Other times I buy parts and no lag at all... sigh.  At least I know when I'm being less than helpful... lol.  These intermittent issues are hard to nail down. 

Thought I'd pass it along - tried to get it to do this in stock, but haven't made it happen yet.   It's somewhat random even on my modded install.  I don't know if its mods or just that in general these issues take a lot longer to occur with stock due to the lower total memory usage and slower heap growth.  Or maybe I'm just not noticing in stock because the delays are much more brief.  Idk.   If I see it I'll certainly report back.

I didn't notice this behavior before MemGraph - but I know well enough that doesn't mean squat.

As always, thanks again for the mod; I wouldn't be playing the game without it.  And I really hope Squad is reading this thread.
 

 

PS. Clarification on my language, I was taught/learned that "soft page fault" = its already in memory, the OS just needs to tell it where, "hard page fault" = not in ram, gotta go get it from the disk.  But I've noticed some people use those terms differently.  I have no idea who/what is right (i've seen some people use major/minor) so I thought I'd clarify how I was using the terms.

EDIT:

Caught it going even higher, nearly 120k page faults, i saw deltas before/after this shot in the 30-60k range.  Memory & I/O spike about the same.   I think I just alt-tabbed out to Procexp faster this time.  (Ignore the total user time, I was doing other stuff on the net running kerbal in the background to see if that had any effect on total memory growth/heap size.  Short answer: no)

 

Edited June 1, 2016 by Tig
clarification. another screenshot.

[Padishar]

2 hours ago, Tig said:

I did find a correlation with those long lag spikes I'm sometimes experiencing.  Seems to be related to a high number of page faults.

I'm really not sure about this one but I have to wonder if Windows isn't simply trimming the working set because a large chunk of KSP's RAM usage is not accessed very much but every so often KSP/Unity does a purge of assets that aren't required and this (or some other similar Unity quirk) results in a hit on virtually every page causing them all to be loaded back in (and whatever has been stuck in the physical RAM in the meantime to be swapped out first).  Like you say, on SSD it probably shouldn't be this slow though we are talking nearly 2 GB of data to shift (and up to another 2GB to shift the other way) and the access pattern could easily be quite random, avoiding sequential reads and adding more overhead, so it's possible.  One thing to check would be to run baretail (or similar) on your output_log.txt and see if it says anything around the times it happens...

[Galenmacil]

Man, one thing is certain: Modern memory allocation mechanics are complicated to say the least!

A "War Story":

Spoiler

 

Back in the early 90's (yes, I am "that" old! ), when I was learning assembly language on 386/486 architecture, memory allocation was simpler. You would use the "stack" or machine registers for temporary storage, preallocated memory for long arrays or other pre-fetch table/whatnot's and, finally, OS dynamic memory allocation via "malloc" function or a direct call to a system interrupt handling that for the other cases.

Like in C, as the programmer, you were responsible for freeing that memory once you were done with it. So, for maximum performance, (and we needed that on a 33mhz 486 DX CPU!) you would allocate only when needed and would keep the pointer to that allocated space for as long as possible, tweaking the code if you had to, to prevent frequent reallocation.

Thinking of it now, we sure were limited compared to today machines but, we were in total control: No multi-threading to think about (well, system interrupt request had to be taken into account...), no "automated memory freeing and compaction" mechanism where in place...

 

Today, it seems the system is like a complex organism with a multitude of things happening at the same time most of them hard to control by the programmer. Expanded possibilities, yes, but at a greater cost in potential performance. In short, the machine is never used to it's full potential in a complex software like a video game.

OK, I took a side road here, back on the main track. Very interesting and informative thread. I am going to add my "experiments" to it. I still have that dream where KSP is stutter free, even when modded to the extreme. Perhaps one day! In the meantime, Padishar's MemGraph sure is helping a lot.

 

Here a few pictures of MemGraph. The graph shows the same thing but under different circumstances from the moment it appears on screen (During game loading) until a save game is fully loaded, waiting at the KSC map until it is completely drawn, from left to right. The following PadHeap.CFG file was used:

Spoiler

8        : 1690000
16        : 1260000
24        : 1010000
32        : 8400000
40        : 7200000
48        : 6300000
64        : 5000000
80        : 4100000
96        : 3500000
112        : 3100000
144        : 2400000
176        : 2000000
208        : 1700000
240        : 1500000
296        : 1200000
352        : 1000000
432        : 8000000
664        : 4000000
800        : 200000
1008    : 0
1344    : 0
2032    : 0

 

Modded game without padding execution. Bottom section shows Windows Resource Monitor for the 64 bit KSP executable at the time of the screenshot:

This is my main KSP 1.1.2 heavily modded save game. It is in the middle of a career with a dozen active satellites and lots of debris in different orbits. Note that I limit the framerate to 50 mainly to prevent graphical glitches with Scatterer ocean. Pretty much all popular mods are used but also many custom tweaks: I delete parts I do not use or want including all interiors for IVA (I do not do IVA). Many customs textures are used from Kerbal faces to planets surfaces, clouds, etc... Lot of background computation caused by mods like RemoteTech, ScanSAT, KeepFit, TACLS, Kerbal Alarm Clock to name a few.

To summarize, something clearly is wrong with the game in this state! GC every 6 seconds that completely stall the game for about 100~150ms when first starting playing but that extend to probably 300+ms after a few scene changes. Very annoying but hey, I like this game a lot and playing it unmodded is out of question!

 

Here, the same save game but this time, padding was executed (via alt-end) as soon as it was possible:

Day and night! But a ridiculous amount of RAM is needed! GC still stall the game for the usual 100-150ms and growing the longer I play. This is at the KSC map. In game, GC happens every 120 seconds or so. Without the padding, in-game, GC stall the game every 15 seconds!

 

Finally, here is a graph of the "Stock", unmodded 64 bit game with a fresh save:

Here, GC happens roughly every 80s but are so quick, that even at 145+ FPS, they are barely noticeable. For me, playing the stock 64 bit game @ 60 FPS, as of 1.1.2, is a completely stutter free experience... But so many things are lacking. I.e. no mods.

 

From this, I can say without hesitation that, on a heavily modded game, MemGraph heap padding trick is a game changer! From my experience I can also say that the more mods you have, the more "stuttery" it gets. Some have a deeper impact than others: FAR for example. With just this mod and nothing else, stutters starts to become noticeable. I would assume that the more complex the mod, the more profound the impact.

Edited June 2, 2016 by Galenmacil

[Wiseman]

10 hours ago, Padishar said:

Well, your reports are already useful as they clearly show that something is being exceedingly rampant in its garbage creation (it might be interesting to try the same thing without the heap padding to see what the stutter is like then ).  Those peaks you are seeing, at what looks like a pretty regular interval, are often going out of the top of the graph, so more than 256 MB/s, which is just insane.  You have a lot of mods installed and there's a fair few I don't recognise from their toolbar buttons so it's tricky to suggest any likely culprits.  I would probably start by removing purely cosmetic mods and testing again.  Then, try without any mods that you can think of that might do things on a regular schedule (KAC, auto-backup, life support etc.).  It certainly shouldn't be anything to do with purely part based mods (unless they use stock KSP modules in really bad ways) so you can probably ignore most of those.

Edit: @Wiseman, for career only I guess the most likely thing is something contract related.  Do you have Contract Configurator and a shed load of contract packs?  If so, try removing that (or anything else you can think of that might be career only).  Also, probably worth doing a Science mode run too in case it is something to do with science experiments instead...

Edit 2: It's probably also worth testing a stock career game to see if that does anything similar.  It may be a stock career issue that is exacerbated by mods...

So, I followed up with some testing for the last hour or two. Yanking the visual mods helped a little, but only by a small degree. I spent some time isolating the two things I thought were most at fault - OPM for the map-view stutter, and Contract Configurator (and a giant pile of contract packs) for the general stutter. Each one, even in a pure stock install, seems to cause fairly significant memory spikes. 

Just like Galen saw in the previous post, I saw zero spikes in a bone-stock install, so it's gotta be mod interactions. I've dropped a bunch of info on the OPM and CC devs, so I guess we'll see!

[Padishar]

On 6/2/2016 at 3:49 AM, Wiseman said:

OPM for the map-view stutter

As mentioned elsewhere, I have submitted a pull request to Kopernicus to (mostly) fix the garbage issues with its on-demand planet texture loading code.  I also plan to make another optimisation to reduce the garbage further.  In the meantime, you can use the following MM patch to disable the on-demand textures (thanks to @Sigma88):

@Kopernicus:FINAL
{
    %useOnDemand = False
}

Just save that as, e.g. disableOnDemand.cfg somewhere in your GameData folder and it should totally eliminate the thrash from moving the camera in the map view/tracking station.  KSP will use more memory as it will keep the textures for all planets loaded all the time but if you've got plenty this will probably be preferable.

[Wiseman]

13 hours ago, Padishar said:

As mentioned elsewhere, I have submitted a pull request to Kopernicus to (mostly) fix the garbage issues with its on-demand planet texture loading code.  I also plan to make another optimisation to reduce the garbage further.  In the meantime, you can use the following MM patch to disable the on-demand textures (thanks to @Sigma88):

@Kopernicus:FINAL
{
    %useOnDemand = False
}

Just save that as, e.g. disableOnDemand.cfg somewhere in your GameData folder and it should totally eliminate the thrash from moving the camera in the map view/tracking station.  KSP will use more memory as it will keep the textures for all planets loaded all the time but if you've got plenty this will probably be preferable.

That fix works great! There's still a spike in memory usage at first, but I can view the planet without the rapid-fire stuttering. Thanks again!

[N1njawarrior]

Good news, I fixed my ram, so now I can actually use this mod. 

[spacehorse]

@Padishar, one question if I increas the heap space will this give me some advantage? If yes what I need to adjust , I am a bit struggeling with the numbers ;-)

I increase already to 9000 MB with put one 0 behind every line but what I need to put if I would like to use 16GB? (I have total 32 GB)

Many Thanks in advance!

Edited June 5, 2016 by spacehorse

[Padishar]

29 minutes ago, spacehorse said:

@Padishar, one question if I increas the heap space will this give me some advantage? If yes what I need to adjust , I am a bit struggeling with the numbers ;-)

I increase already to 9000 MB with put one 0 behind every line but what I need to put if I would like to use 16GB? (I have total 32 GB)

Many Thanks in advance!

Increasing the amount of padding should always increase the time between the stutters until the point where your machine decides to start using virtual memory.  However, the benefit is likely to be outweighed by the increased time it takes to do garbage collections at some point.  The numbers in the configuration are simply the number of blocks of each size that are pre-allocated.  The approximate usage for each size of block can be calculated by multiplying the count by (size + 16) though this will come out a bit low especially for the larger block sizes.  Simply calculating the ratio between what your current settings give and what you want and then multiplying all the numbers by that ratio should get you to (roughly) where you want though it would probably be beneficial to add some padding for some of the larger blocks too (e.g. for 664, 800 and 1008, the others start to get really wasteful).

[spacehorse]

Sorry I think I am on a wrong way maybe i too stupid....., can you give me please one line as an example?

 

And thanks for your fast Response :-)

@Wisemanand by the way the coperncus topic i tested so the workaround bring in my Situation unfortuntely nothing.

Edited June 5, 2016 by spacehorse

[Padishar]

2 hours ago, spacehorse said:

can you give me please one line as an example?

Right, assuming the default config adds 900MB and you want it to use 16GB then divide 16000 (1 GB is approx 1000 MB) by 900 to give approx. 17.8.  Now change all the lines in the file by this amount, e.g.

8        : 1690000
...becomes:
8        : 30082000

You don't need to be particularly accurate so could just use 30000000 in this case.

[spacehorse]

Many Thanks :-)

[Badfish]

Hey, thanks a lot, this mod works great.  I didn't want to admit how much the stutter bothered me until now, it was brutal even when only lasting 200 ms.  Before the frequency was 5 to 7s, now its 60 to 75s.  I only use my computer for Kerbal so I added a zero for each value in the cfg and it works good so far on 16gb, but I haven't done any big launches yet.  

A great program I use now is Project Lasso.  I set KSP to permanently run in real-time on cpu and only have affinity for actual cores (which I think helped run-time) and have max priorities.  I also set everything else that I could to only run on one core and have minumum priorities for I/O, CPU, and memory.  Hopefully I didn't hamper anything that KSP relies on, but with a 2.5GHz I7 it's running at more than half-speed with 250 part ships landed on almost max graphics settings.  I did put max delta physics to 0.07 though.  Keep up the great work!  

P.S. Someone else mentioned an idea for a mod that would help run-time by splitting one ship up to run on multiple cores.  I was thinking of trying this out in a manner similar to how people used to build helicopters.  If you could lock two ships together that aren't physically joined maybe the game would process physics more parallel.  You build in the VAB with a decoupler at the joint and on the pad you decouple, with some combination of parts that hold the two together.   I don't know how strong such a connection can be though.  We keep hearing that Unity is going upgrade their multi-threading but who knows what that means for KSP.  

[hirschhornsalz]

Great Mod. I was able to reduce the stutter from every 2 oder 3 seconds (I suspect the problem seems to be worsened with Kopernicus/New Horizons) and really unplayable to a 4 minute, barely noticable stutter. I multiplied the values in padheap.cfg by 20 and running at about 22 GB memory consumption on a 32 GB rig.

[Padishar]

34 minutes ago, hirschhornsalz said:

Great Mod. I was able to reduce the stutter from every 2 oder 3 seconds (I suspect the problem seems to be worsened with Kopernicus/New Horizons) and really unplayable to a 4 minute, barely noticable stutter. I multiplied the values in padheap.cfg by 20 and running at about 22 GB memory consumption on a 32 GB rig.

You're welcome.  If you think Kopernicus is contributing to your stutter (which it probably is) then try out the test version in this post:

 

[TrooperCooper]

 

From the 1.1.3 patch-notes:

* Reduction in the creation of Garbage Objects in Flight scene.
* Reduction in the creation of Garbage Objects in Space Center.
* Optimize Part.GetConnectedResources and Vessel.GetActiveResources for speed and to not create garbage.

I am still on 1.1.2 since I play a heavily modded RSS/RO career. So I am gonna wait for the mods to update before checking out 1.1.3. But this might help with our issue.

 

Edited June 22, 2016 by TrooperCooper

[Padishar]

3 hours ago, TrooperCooper said:

I am still on 1.1.2 since I play a heavily modded RSS/RO career. So I am gonna wait for the mods to update before checking out 1.1.3. But this might help with our issue.

It does.  A number of the garbage improvements in 1.1.3 were done as a direct result of the various investigations done and bug reports submitted.

Specifically, the issue with on-rails vessels described in this post:

...was addressed.  The case that was allocating ~4900 KB/s now allocates ~500 KB/s (nearly an order of magnitude improvement).

The editor parts list issue described here:

...was also significantly improved (I think the largest stock category has gone from ~5 MB/s to ~300 KB/s) as was the issue in Part.GetConnectedResources that I've been trying to get fixed since I posted about it here:

...resulting in the station in my avatar that used to allocate ~180 MB/s while the RCS (there are 288 4-way RCS blocks on the vessel) was firing, to now allocate ~12 MB/s.  This is substantially less than the 32 MB/s it allocates when the RCS isn't firing though this is because the framerate drops from 11 to 4 due to the extreme CPU usage of the monoprop transfers and most of the remaining garbage is generated by the FixedUpdate processing which is called much less often as a result.  Yes, this is still rather a lot, but the remaining big offenders have been identified and reported to Squad (in this case, docking ports do about two thirds of it and the rest is mostly the solar panels and probe cores).