Padishar

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

Ahhh, sorry, I thought the example in your post indicated you had 16GB. Yeah, if you haven't got much physical memory free then it might well do more harm than good, even at the default settings...

While I basically agree with your second paragraph that there is no point converting the format to XML so you can use an XML library to read it, (the conversion process, by definition, must be decoding the data out of the format in order to generate useful XML so just use the data directly) the first paragraph isn't particularly related. It is significantly harder to write a program that can remove parts from vessels in flight as the linkages between the parts are stored differently in the .sfs file than in a .craft file. In a craft file you can basically just strip out whole parts as you feel like but, if you do the same in a save file then it is highly unlikely to load because references to other parts are specified as indices into the part array of the vessel and removing parts will change the index of every following part. For this reason, when messing with vessels in save files, you really need to load the data into an in-memory structure that resembles the actual layout of the file, so that, when you write it out again, you can fix up the part references...

Yes, though it does seem a bit strange. I've run some tests with different combinations with the following results (on my old, CoreDuo, laptop on Win32 so, in no way directly comparable to my earlier results, but still interesting). I split the disabling into 4 parts: crew, props, trucks/lifts and lights. KSC: 25-30% VAB Nothing disabled: 65-75% VAB Crew disabled: 65-75% VAB Crew and props: 65-75% VAB Crew and anims: 65-75% VAB Crew, props and anims: 25-30% VAB Lights disabled: 65-75% VAB All disabled: 25-30% dropping to 12-15% after about ten seconds. So, basically, turning off individual ones didn't have any obvious effect on the CPU usage but turning off everything except the lights reduced the usage to approx. half a core. Also turning off the lights basically halved this again though turning off the lights without disabling the other bits had no apparent effect. So, as far as this potato of a machine is concerned, the most important thing is to kill the crew, props and trucks/lifts. Killing the lights as well is also helpful but does make the VAB look quite a bit different so I would probably rather leave it on, especially as killing the other bits gets the CPU usage to the same level as KSC. I'll run the same tests later on my decent machine to see if the pattern is repeated... What is the model_props GameObject? I looked for something obviously changing when turning it off but couldn't see anything (I may be being totally unobservant here ). I can understand that the animated stuff would use CPU (though the amount seems a tad excessive) but not something that seems to be invisible anyway.

Thanks for the reply. What makes you think that changing any of the settings files causes MM to ignore the cache? As far as I'm aware, MM only rebuilds when files that are loaded into the GameDatabase change and the ones from this mod aren't due to them being in the PluginData folder. In any case, MM specifically logs the names of the files that cause it to rebuild so, does your log explicitly say that one of this mod's ,cfg files caused a rebuild?

I posted this over in the crashing thread before realising this one existed...

Great job, thanks. I've just tried this in the context of VAB CPU usage and it does look like one of things it's disabling is the cause. I'm now getting around 5-8% usage in the VAB where it is 25-30% without the mod. I can't tell if it's the lights, the trucks/lifts or the crew (though I have those disabled anyway) so it might be an idea to split it into several plugins that disable one (type of) thing each...

I have now released version 1.0.0.7. This adds readouts of the minimum (just after GC) and maximum (just before GC) heap sizes and the time between the last two collections. It also makes the heap padding configurable via a text file. The default settings now allocate approx. 900 MB of padding and the screenshot in the OP now shows the effect of running this. Before the padding the collections were happening at 13 second intervals and after the padding this increased to 44 seconds. Modifying the configuration to allocate around 2.5 GB of padding increased it to 112 seconds. Edit: @p1t1o, now that it's configurable you can simply edit the values in padheap.cfg, e.g. if you add a 0 on the end of all the counts then it should allocate more like 9GB extra. If it does work and does give a decent extra effect then you might want to tune it back a bit to give you more headroom. The counts in the file are simply counts of the number of pre-allocated blocks to create for each block size. The current values are fairly arbitrary, simply based on sharing the total padding fairly evenly between the block sizes with a considerable bias towards smaller blocks which was experimentally determined to improve the effect in the limited number of situations I tested.

This is a very common practice when you don't need all the features of XML. A well written, simple text parser should be substantially more efficient than any full-blown XML parser. Also, the extra cruft in XML files tends to make them harder to read...

This is totally normal, it is telling you which line of code in the unity player is doing the writing to the log. I'm not saying this info is of any use to the user, or that it should be output at all, but it is (and has been in every version of KSP since at least 0.23) completely normal and isn't responsible for your apparent slowdown.

I'm sorry, I simply don't understand what you're trying to say. If you're trying to report an apparent problem caused by this mod then you'll need to accurately describe what you did in the session (with, I presume, details of the memory usage of KSP at different times during the session, including exactly which measure of memory use you are quoting) and, preferably, post an output_log.txt/player.log file of the session. To be really thorough, you should repeat the whole session without using the heap padding so a valid comparison can be made.

What are you trying to imply? In what way is that not totally obvious from all these:

On a mac I guess it would be option-x

After doing the "delete local content" you should also go to the folder and remove all trace of the "Kerbal Space Program" folder because Steam will leave behind any files that it didn't originally put there.

This is a very scary statement on several levels. Do you often install programs on your computer that you know so little about? Uploading an output_log.txt file (see the "How to get support" sticky thread for details) from a run of the game that has at least one of these random failures (or reading through it yourself) would almost certainly locate the mod concerned almost immediately...

Just in case anyone following this thread hasn't seen it yet, I have now implemented this "heap padding" mechanism in my MemGraph mod linked in my sig below. It took a little longer than "a few minutes" to get it working reliably, the initial tests worked but only for one or two runs of the GC, after which Unity/Mono would discard the padding and the improvement would disappear. After research into the low-level details of how the Mono heap management works, I have devised a way of padding the heap in such a way that Mono can't get rid of it. This mechanism can result in the interval between stutters being increased significantly though it is highly dependent on the pattern of memory allocation (I've measured between 3 and 12 times in various situations and others in the thread have also reported similar and that they consider it a significant playability improvement).

Ahhh, the heap padding increases the memory usage of KSP by a little over 1.5GB (at the main menu my x64 KSP on Windows has a commit size of 2.2 GB and this rises to 3.8 GB after doing the padding). This will cause a machine with only 4GB of RAM to have a bit of a fit so that isn't really a surprise. I will be modifying the padding mechansim to make it tunable which should allow it to be used on a machine with only 4GB, though since the whole point of it is to trade memory usage against GC frequency, the benefit with so little RAM will never be great. Edit: I have edited the first post to make it clear that it currently wont work well with only 4GB of RAM.

There is a possibility that the Mac build of Mono uses slightly different private data in each memory block resulting in different block sizes or simply tracks different block sizes to the windows build. If this is the case then there may be no padding created for one or more block sizes which would reduce the effectiveness. I am surprised that it would make the performance worse though. What do you actually mean? Are the GC stutters closer together after padding the heap or does the game just run slower in general (the U value in the window is basically fps)? How much RAM does your machine have? Any chance you can do a test exactly as described in the first post and then upload your player.log file?

Sorry for the delay, I forgot to update the test version as mentioned above. I have now done so here. There is a possibility that this might do something a bit weird in the situation where the bug occurred but, as I don't actually know what that situation is, I can't be sure. I believe the rendezvous panel needs to be open and you need to have had a vessel target but I'm not sure of the exact cause.

Edit the post, click on the bit where it says the time and author of the quote and then hit the delete key.

No, I certainly wouldn't say that but I would say that the release of 1.1.2 was 4 weeks ago now, the devs have been back for a few days and are working on the problems and continued, non-constructive, whining isn't going to accomplish anything (except for stirring up ill feeling) so you may as well save the wear and tear on your keyboard. There are certainly things that need to change and you would be mistaken if you think that Squad aren't well aware of it. If you aren't going to, at least, suggest what those things might be then, again, I suggest you simply save the wear on your keyboard.

I'm pretty certain this one's already on the list to be fixed. It's a safe exception caught inside the KER code so it can't cause any issues for other parts of the program. Edit: in fact, there was one of these in one of the earlier logs Galenmacil posted and I added some extra logging to the code concerned in the test version I posted. However, this logging code was looking at the wrong thing so didn't add anything helpful though this fact indicates exactly what the actual issue is. I'll post another test version later today that should eliminate the issue.

I'm absolutely certain he realises what's going on because I've read lots of his other recent posts which make that fact quite clear. As for the rest of your post, do you really think that such a non-constructive, inaccurate, rant is going to have any positive effect on the situation?

The 1.5 GB is as a result of my testing in a limited range of situations and I do plan to tune the padding mechanism further and also allow the user some control over it. Due to how the memory allocator and GC work, it isn't currently possible to forcibly pad the heap for large block allocations (this is anything over 2032 bytes) and it is very inefficient on memory usage to pad it for blocks above 500 bytes. These factors combine to make the improvement highly dependent on the pattern of memory usage (specifically, how many blocks of what different sizes are being allocated). If the memory usage was (virtually) all in small blocks then the improvement would be considerably better. Large blocks have to be allocated directly from the normal heap headroom that Mono maintains (rather than the "pre-allocated blocks" that the padding mechanism creates) and this is simply a proportion of the total heap size (and it looks like Unity deliberately reduces this proportion as memory use increases to prevent too much free memory being retained ). Increasing the padding does generally always increase the time between stutters but the benefit shrinks rapidly as the heap gets larger and, yes, the padding results in a lot more work for the collector (though I'm also investigating a cunning way to minimise this).

What surface gravity is it going to have? What rotation speed? How big is the SOI going to be? How long will it take to orbit around it? Trying to answer any one of these questions will make it obvious that this really isn't going to be practical...