Weird thing that makes KSP temporarily use *vastly* less RAM

[Tiron]

Okay, so I was in the middle of an atmospheric flight when I had to leave for my Grandmother's for Memorial Day stuff. So I suspend my system (Windows 7, used 'sleep', I still haven't turned Hibernate back on since I got a new hard drive), and today I get home, bring it back up, recommence my flight, chatting with people on IRC. Get to talking about Mapsat using tons of memory to load the maps. I go to check my Memory Usage.

~800,000 KB. Wait what?

KSP has used ~2,400,000 as long as I can remember. Lately it's been a bit higher, probably because I started using Modular Multiwheels fairly recently. During specific checks I've found levels in the neighborhood of 1,800,000-1,900,000 without a mapsat module or 2,500,000-2,600,000 with a mapsat module. Suddenly it's using a QUARTER of that. After I land, I go back to the SPH and load a new craft, it climbs. To ~1,800,000. I go back into the SPH, put a mapsat dish on it, and reload. About ~1,900,000.

So I test it by leaving a plane sitting on the runway and suspend->unsuspend again. It comes back up using ~380,000(less at first, it climbed pretty quickly once I started doing stuff.) Something in the process of suspending and unsuspending windows is unloading massive amounts of KSP's data from RAM. And it is to all appearances COMPLETELY FUNCTIONAL that way!

One thing that DOESN'T change is the 'Commit size', which according to Microsoft is just the memory that's allocated to the program. Which makes sense, it's obviously not something that's intentional, so it makes sense that it'd still be requesting the same amount of memory as normal, even though it's suddenly and mysteriously not using anywhere near that much.

I don't know how useful it actually is (the commit is still just as high as normal, and you're still going to spike during the loads), but it does seem like it has some potentially interesting implications.

[Wjolcz]

I've also noticed that when you have lagsbane turned ON when on launchpad you can just do 4x physics accelerate and then back to 1x the slowness magically disappears!

[Brofessional]

Windows 7 uses superfetching.

Having idle RAM is just a waste, so it keeps recently accessed data in the RAM in-case you access it again. If another program comes along and needs the space, it will dump the superfetched data to make room.

When you sleep/hibernate or shutdown, it dumps the data. So as you mentioned, it climbs back up again after you resume play.

For example if you boot up your computer and start photoshop, it might take 15 seconds to open the application. Then if you close photoshop and immediately open it again, it will only take 2 or 3 seconds to open because the data is still loaded.

[Tiron]

Windows 7 uses superfetching.

Having idle RAM is just a waste, so it keeps recently accessed data in the RAM in-case you access it again. If another program comes along and needs the space, it will dump the superfetched data to make room.

When you sleep/hibernate or shutdown, it dumps the data. So as you mentioned, it climbs back up again after you resume play.

For example if you boot up your computer and start photoshop, it might take 15 seconds to open the application. Then if you close photoshop and immediately open it again, it will only take 2 or 3 seconds to open because the data is still loaded.

That would explain it, but it raises another question... if it's supposed to dump it if needed, and KSP evidently needs very little to run on, even with some very memory-hogging mods turned on... Why is it still generating out-of-memory crashes for people if most of what's there is Superfetch stuff it's not actually using?

I mean, part of my brain is niggling that you'd probably still get out-of-memory if the commit went over the possible allocation, but it still seems...kinda dumb.

It also seems like, if that's the case, there ought to be SOME way to exploit it to stop all the out-of-memory crashes people with a lot of mods are getting... (to a point anyway, but at least get it so that if you can get everything loaded you don't end up crashing later because of a fluctuation in memory usage).

Edit:

Okay, so I looked at some more stuff. Apparently Superfetch is actually designed primarily to help load Windows and Programs faster, and what we're looking at here is some kind of more traditional caching system, which it also has.

I did notice one other thing, however. In looking up this stuff I found a guide to what all the different 'Memory' readouts in the task manager are. They listed 'Private Working Set' as being the memory the process is using that it will NOT 'share with another program'. Now if I interpret this correctly, this seems to refer to the fact that Superfetch/Cached memory is supposed to cede what it's using if something else needs it, leaving the Private Working Set to be the the things the program's actually actively using at the moment.

When I flipped that column on, I found that KSP's "Private Working Set" was only infinitesimally smaller than the Full Working Set. I then immediately went into suspend mode on it, and came back up, and again found only a few hundred MB used.

It's almost as if everything the game loads at any point gets cached, and that the cache is for some reason being flagged as actively in use when it's actually not. Somehow Suspend is killing it anyway, but not the commit allocation. This could account for the 'memory leak' that some people have observed: It's not so much a leak as a case where things are only being loaded as they're used, but never really get unloaded. This would cause the memory usage to climb throughout a long play session as more and more bits were loaded at some point or another. Most of the memory that's flagged as 'in use' isn't actually being used, but because of the way it's flagged, it doesn't get reallocated.

My observation after going on suspend mode is that it has no trouble whatsoever loading things on the fly. So if it were somehow set up to either unload things entirely or at least flag the presently-unused stuff as being able to be reallocated, it could help some people out rather dramatically.

Edited September 3, 2013 by Tiron

[KerbMav]

Thoughts of a half-user:

KSP loads all data upon start into the RAM to be readily available if anything comes into rendering range.

It is limited by its 32bit structure.

Windows uses harddrive memory to dump data from RAM; KSP seems to only allow this while the OS is hibernating.

Now - on systems with lots of memory - if KSP were designed to request Windows to create a ramdrive reserved for the game to store its during startup preloaded data and if KSP then would fetch its data during play from this ramdrive to load it into RAM - would this equal "profit"?

The game would still be able to preload every part and texture, but as it dumps these onto a Windows managed ram drive - that is not limited by the 32bit dilemma, as KSP only sees a (very fast) drive - it would still be able to use the 3,x GB of RAM it can handle.

So, it should be possible to install more mods than would fit into the 3,x GB of KSP usable RAM - the only limitation then being, that there must not be more parts and/or retextured high-res planets in rendering range than can be loaded into KSP usable RAM.

Am I making any sense?

[magnemoe]

Windows 7 uses superfetching.

Having idle RAM is just a waste, so it keeps recently accessed data in the RAM in-case you access it again. If another program comes along and needs the space, it will dump the superfetched data to make room.

When you sleep/hibernate or shutdown, it dumps the data. So as you mentioned, it climbs back up again after you resume play.

For example if you boot up your computer and start photoshop, it might take 15 seconds to open the application. Then if you close photoshop and immediately open it again, it will only take 2 or 3 seconds to open because the data is still loaded.

However superfetch who is an advanced disc cache should not affect KSP memory use it only uses memory who is free for windows.

Virtual memory also does not affect KSP memory limit or use.

My guess is that hibernate cause the game to reorganize itself and dump unused stuff somehow

[FITorion]

I've heard that KSP loads the textures for each part into memory even if those textures are already loaded from another part using the same textures. So with lots of parts you end up with copies of the same texture loaded in RAM. KSP hasn't really gone through an optimization phase. They're still adding core features. We are however seeing stand in things being replaced by optimized final versions... the New space center is an example. But really what's needed is an optimization pass... where they would for one... make the textures load only as needed and keep only one copy of the texture in RAM and have all parts that use it just reference it.

[Tiron]

Thoughts of a half-user:

KSP loads all data upon start into the RAM to be readily available if anything comes into rendering range.

It is limited by its 32bit structure.

Windows uses harddrive memory to dump data from RAM; KSP seems to only allow this while the OS is hibernating.

That's the thing though, it's NOT dumping it into the page file while it's suspended (I haven't tried Hibernate, because it's disabled on my system. Suspend saves the System state into RAM and keeps the RAM powered so that it's not lost. Hibernate Saves the system state to the Hard Drive and as such can power down more fully. Because Suspend just goes to RAM, it's a lot faster, but it's also susceptible to power outages. Cutting power to a suspended system has the same effect as cutting power to the system in normal operation. But because Hibernate is saved to the hard drive, if the power is cut, the system can still resume from where it left off at. Downsides to Hibernate are the much longer time it takes to write the state out to the hard drive, and the fact that you have to reserve a few GB of hard drive space so that there's definitely room to do it. I used to only have a 150gb HDD, so I turned Hibernate off to free up some space. Now that I've got a 2TB I've just never gotten around to turning it back on.

As for dumping things to the swap file, that'd be...counterproductive. The whole point of suspend is that it's fast, because it only uses the RAM. Dumping things onto the hard drive (Swapfile or otherwise) would drastically increase the amount of time it takes, and it'd be obvious it was doing it: there'd be a ton of hard drive writes while you were waiting for the system to suspend.

I've heard that KSP loads the textures for each part into memory even if those textures are already loaded from another part using the same textures. So with lots of parts you end up with copies of the same texture loaded in RAM. KSP hasn't really gone through an optimization phase. They're still adding core features. We are however seeing stand in things being replaced by optimized final versions... the New space center is an example. But really what's needed is an optimization pass... where they would for one... make the textures load only as needed and keep only one copy of the texture in RAM and have all parts that use it just reference it.

Well, the thing I noticed personally is that ISA Mapsat's maps are using up about 20MB of RAM per map, which really doesn't make much sense, but this whole situation almost provides a plausible explanation:

It loads the ~2mb png file into memory, decompresses it into a ~8gb file, also in memory. Passes it to OpenGL (there's another 8GB), which converts it to a DDS (~2mb again) which then gets passed to the vidcard. At that point, most of that usage is redundant.

Going to be looking into some more specialized software though, to try to see if I can't track what's going on here a little better.

Assuming I'm right about this and it's not just a display problem with the way task manager indicates things (which it could admittedly be), the problem could be more-or-less resolved without bothering to do an optimization pass. If most of the memory usage really is cached items that aren't actually being used at the moment, all you'd have to do is set it up in such a way that it could dump part of the cache and reallocate the memory it was using when something new needed it. The memory usage would still LOOK high, but it wouldn't crash unless you actually managed to get it to where it was actively trying to load more than ~3.5 GB of stuff.

If it's caching things and not re-using the cache when it reloads that thing, that's pretty much your typical textbook memory leak. From what I've seen of the current structure, though, it really doesn't allow re-use of the same texture/model for different parts unless you're completely re-using both of them. This means, practically, that each part ends up with its own copy of the texture, even if another part uses it. That doesn't really give the game a way to be able tell it's the same texture, though, so it's treated as if it wasn't.

[KerbMav]

That's the thing though, it's NOT dumping it into the page file while it's suspended...

Still, you got me rambling in my brains about a different take on preloading data while possibly evading the limitations of RAM usage by 32bit programs and not falling back to sluggishly slow HDD memory.

[Motokid600]

You know I swear there's a memory leak somewhere. My gamedata folder is about 1.5 gigs. I'll build a massive rocket and find myself swapping back and forth from the VAB to the pad to make tweaks a dozen times. Game runs great, but on the 12th time it'll crash when loading the craft onto the pad. Sometimes it'll crash in the VAB after an hour of construction. It's as if the memory just builds and builds until a crash. So..if there's a way I can off load it every 20 minutes of play then that'd help alot.

[LameLefty]

You know I swear there's a memory leak somewhere. My gamedata folder is about 1.5 gigs. I'll build a massive rocket and find myself swapping back and forth from the VAB to the pad to make tweaks a dozen times. Game runs great, but on the 12th time it'll crash when loading the craft onto the pad. Sometimes it'll crash in the VAB after an hour of construction. It's as if the memory just builds and builds until a crash. So..if there's a way I can off load it every 20 minutes of play then that'd help alot.

My experience is similar to yours, even though I'm using OS X. If my build sessions in the VAB last very long, crash when I try to launch. If my flying/mission operations sessions last too long (an hour plus, generally), crash when I go to the Tracking Station. It seems more often if I switch missions or ships several time.

[Tiron]

You know I swear there's a memory leak somewhere. My gamedata folder is about 1.5 gigs. I'll build a massive rocket and find myself swapping back and forth from the VAB to the pad to make tweaks a dozen times. Game runs great, but on the 12th time it'll crash when loading the craft onto the pad. Sometimes it'll crash in the VAB after an hour of construction. It's as if the memory just builds and builds until a crash. So..if there's a way I can off load it every 20 minutes of play then that'd help alot.

I dunno if it'd actually help, because I'm pretty sure if the commit hits 4GB you're in crashville, and that's staying high.

Size of gamedata isn't a good way to accurately judge memory usage though, because textures for example seem to get vastly inflated. If it's caching all the intermediates involved in getting the texture to the vidcard, that would make sense.

Caching things in and of itself isn't bad: If it's reusing them when it needs them again later, it'd actually speed up loading quite a bit. What would be bad is if it's not reusing the cache and if it's not allowing the cached bits to be dumped to make room for other things when needed. It doesn't really seem like it is allowing the cache to be dumped given how many people complain about out of memory crashes and how far it drops when you suspend.

Yes, you could hit a point where you were just loading so much stuff that your peak load got too high, but I don't get the impression that's happening at all from what I've seen. I have some ideas about checking that by deliberately inflating my memory usage, but I've got about three different things I want to test at the moment and trying to trace the memory is evidently quite ugly for a pre-compiled application (which doesn't surprise me a bit.)

I've only ever dabbled in programming really, so it's something that's completely new to me and I'm trying to figure out how to do it as I go. Yay.

[Rakshasa]

Someone discovers the wonders of virtual memory two decades after it became common on personal computers.

BTW, note that the memory size showed using common tools on windows is the resident set size (pages held in physical RAM), not pages allocated, and as such doesn't tell you how much address space you got remaining. Thus you can hit the 4GB, actually 3GB for user process, address space limit even with a very low RSS.

[KerbMav]

BTW, note that the memory size showed using common tools on windows is the resident set size (pages held in physical RAM), not pages allocated, and as such doesn't tell you how much address space you got remaining. Thus you can hit the 4GB, actually 3GB for user process, address space limit even with a very low RSS.

In English Mr Spock!

[Motokid600]

What are the chances we see a 64bit version come .22? Has anyone seen a dev mention it recently?

[KerbMav]

.22 ?

0.0%

[Tiron]

Someone discovers the wonders of virtual memory two decades after it became common on personal computers.

BTW, note that the memory size showed using common tools on windows is the resident set size (pages held in physical RAM), not pages allocated, and as such doesn't tell you how much address space you got remaining. Thus you can hit the 4GB, actually 3GB for user process, address space limit even with a very low RSS.

Well it'd help if the various available metrics were a bit more straightforward about what's going on, exactly. The one thing I've gathered in all this is that they're really not, and that there's no good, consistent way to observe the actual memory usage because it's simply not presented in a clear way.

Regardless, it's my understanding that if nothing else, the working set constitutes the bits it's actually referencing, even when it's not indicative of how much the program is using. The fact that it's dropping by such a large factor and crucially not climbing back up again suggests that there's something interesting going on that I'm not adequately able to probe myself.

It's not a small drop, it's generally somewhere between a factor of 3 and 6. Going through a scene load is the only thing that jacks it up again in a big way, and even then, even after multiple scene loads, it's staying ~20% lower than normal. It rather strongly hints at things being loaded into memory that aren't really being used very much, and just get left there.

People are crashing because they run out of memory, so if it's being wasted on caching things that aren't being used, that's kinda important to figure out huh?

.22 ?

0.0%

The unfortunate fact is that a 64 bit build is dependent on Unity fixing things so that it's possible to do one that isn't titanically unstable.

And frankly, it's not the magic bullet it's been made out to be either. I personally only have 8gb of physical memory on my system, and that's more than a lot of people have. Going to 64 bit would enable me to use, at most, about another 2 GB before it starts paging out to the hard drive in a big way. You think the loading is slow NOW...heh. Wait till it's having to load gigabytes worth of stuff into the swap file.