I noticed that IIM was using a LOT of memory, or at least Windows said it
was. When you'd start IIM it would sit at around 18MB of RAM, then if you
minimized the main Dock window it would shrink to around 1.2MB. And as IIM
sat there it would slowly start using more memory, it looked like a leak but
then all that used memory would go away when you re-minimized the main dock.
weird was going on.
I found some code that could duplicate that 'clean-up'
that was getting done when the main window was minimized. I have that run
whenever a chat window is closed and every minute or so just to ensure that the
user never really sees it using much memory.
Here is what IIM uses:
description for MemoryManagement.
/// This was found on
/// I added the try
catch block just for safeties sake.
/// Also I re-ordered
the actions as they didn't work in the order provided
SetProcessWorkingSetSize(IntPtr process, int
(Environment.OSVersion.Platform == PlatformID.Win32NT)
avoid compiler warning
If you have any questions about the effectiveness, here's a log of
what IIM thinks it's using for memory, both before and after cleanup.
20:43:18,250 [IIM.MemoryManagement.FlushMemory] - Memory used before clean up called 529 KB
20:43:18,250 [IIM.MemoryManagement.FlushMemory] - Memory used after clean up called 476 KB
20:43:55,078 [IIM.MemoryManagement.FlushMemory] - Memory used before clean up called 5302 KB
20:43:55,093 [IIM.MemoryManagement.FlushMemory] - Memory used after clean up called 563 KB
The Jump up to 5302KB was a result of sending a RAW screenshot to another machine in a chat window.
and as you can see from the time stamp, that the clean up does take a bit (15 ms
in the case of flushing 480KB)). If you're writing some massive multi-user,
performance intensive application then this is not the solution for you.
It works just fine for a single user app. The additional used memory
between 476 and 563 is an open Chat window with a screen shot displayed in it.
have noticed that the 563KB is still bigger than the 1.2MB I mentioned earlier.
Unfortunately Windows associated the memory used for the .Net Framework with
your app and tacks it on to what you app is actually using. Using the type
of logging above I've found that the 'memory creep' I was noticing was not due
to the memory my app was using, it was the tacked on framework overheard that