Memory Not Being Returned?

[Xyd]

So I've noticed this lately (in addition to the obvious memory leaks) that when I load up a ship, my memory will go from say 2.4gb to 2.7/2.8gb of ram usage. But, once I'm done with the ship, either through recovery or leaving the VAB, the memory used will not be returned. This is on Windows 32 bit.

Is this the norm? And are the devs working on a fix for this? I'm aware they're working on fixing the memory leaks, but this seems like an entirely different issue.

[SciMan]

A memory leak is exactly what you're describing. Memory being allocated to a program for it to use, but the program doesn't release the memory when it's done using it.

[sal_vager]

As you don't see the memory use go up with every craft loaded, KSP is reusing that memory so it is not a memory leak.

There are known issues with the memory allocated to the part overheating effect, specifically the PPFX edge highlight in the flight scene when parts get hot enough, and this is something Squad are looking to address.

But the memory use from loading a craft is normal, and there are many other things loaded into memory such as terrain, and things are cached to save time in case you go back to them.

[tbob]

A memory leak is exactly what you're describing. Memory being allocated to a program for it to use, but the program doesn't release the memory when it's done using it.

Maybe - if the memory gets bigger next time you load the ship then yes. But KSP may be retaining the buffer for re-use. If KSP still knows it has that memory it's OK. It's only a leak when both KSP and Windows are saying "Where is it? I thought you had it!"

[Murph]

It's absolutely normal for applications to NOT return memory to the operating system, except under very particular circumstances. The type of operations and analysis described here absolutely does not conclusively demonstrate a memory leak. You simply cannot rely on the memory usage reported by operating system tools to identify memory leaks reliably. Constant significant growth over time, which never seems to level out, that's a quite likely pointer towards a memory leak. Reported memory usage not shrinking does not indicate anything in particular, it's perfectly normal.

When application code is finished with a block of memory, the first thing that happens is that it's returned to the application's own internal pool of free memory. When an application needs to allocate a new block of memory it always first tries to obtain it from its own pool of free memory, and only goes to the operating system for more if it does not have a suitable contiguous block available. In some cases, it may never be returned to the OS until the application exits. That is not any type of problem, however, as all modern operating systems work with both virtual address space and virtual memory, so inactive "pages" of memory held by an application should not be having any real impact on either the application or system performance. The problems kick in when there's too many active "pages" system-wide, or an individual application runs out of virtual address space. Historically, there was a 3rd problem, of the system running out of available virtual memory (aka swap, or memory on disk), but modern disk sizes have all but eliminated that in most cases (although you can make that a problem for yourself by badly managing your system).

- - - Updated - - -

Maybe - if the memory gets bigger next time you load the ship then yes. But KSP may be retaining the buffer for re-use. If KSP still knows it has that memory it's OK. It's only a leak when both KSP and Windows are saying "Where is it? I thought you had it!"

Even that isn't conclusive. { load; unload; load; unload; } is an insufficient test identify a memory leak. Idiosyncrasies of internal memory allocation and fragmentation of free memory means that it's not guaranteed for the memory footprint to be identical after either each load or unload in a sequence like that. You require a much longer sequence of load & unload to have any reasonable certainty.