Danke Daniel für den Link, das Thema ist also schon vor anderthalb Jahren jemandem aufgefallen:
"When you minimize the window, the OS does something to the effect of calling SetProcessWorkingSetSize( .., -1, -1 ) to trim the ram usage.
Me:
Thanks! But now I'm curious...why would it only do that when the app is minimized? If it's never minimized, it continues to take up all that memory, which apparently isn't needed?
David replied:
I presume it takes minimisation as a hint from the user to say "I'm not too worried about the performance of this application now"… the OS (if it gets low on memory) can reclaim that allotted memory for other purposes. Your application just has it in its back pocket for the possibility that it might soon need it.
Then, on another tack, Paulo Morgado asked:
Have you tried to run several instances of the application and some application that really needs lots of memory to see if your application releases the memory it doesn't need?
I wasn't quite that masochistic, but Jacob Grass tried it:
I launched a simple winforms app and then launched a memory intensive application. The memory usage of the Winforms app was reduced as expected.
Whew! But as Paulo asked, why does the app take the memory when it doesn't need it? Alun Jones shed light on that issue:
This is one of the big ol' principles of a garbage collecting library, that you don't free up memory that you might need to reallocate again soon, you keep it around in the hope that you'll use it - but you free it if you're told either that you're not going to need it any time soon, or someone else needs it now.
Sadly, it's also one of the things that can make it harder to track down memory leaks - because you don't see the memory go up at allocation time, or down at deallocation, it's difficult to find where and what your memory leaks are. Fortunately, because it's all in garbage collection, the garbage collector can tell you what you're still maintaining at any point. I was amused to find out just how much naive string concatenation in .NET causes memory use to rise. [Use a StringBuilder, and it isn't so bad.]"
Nur bezieht sich das auf Managed .NET, d.h. auf Applikationen die im Kontext des .NET-Frameworks laufen, welches sich selbstständig um die Speicherzuteilung und -verwaltung kümmert. Das wäre soweit noch nachzuvollziehen, wobei aber auch hier die Frage offen bleibt, warum die Applikation nach dem Minimieren und Maximieren mit 5% des Speichers genauso zurecht kommt, wie vorher mit 100%, und warum es nicht möglich zu sein scheint, dass anderweitig und "dynamischer" zu regeln.
Aber was ist jetzt mit den Tools, die nicht auf .NET basieren - bei mir etwa Freehand, Photoshop, Word [...], wo sich also die Entwickler selbst um die Speicherfreigabe kümmern müssen?
Seltsam :-)
