I saw this post at ZDNet about Firefox 3 memory usage,. Setting aside for a second whether Firefox 3 is better than IE 7 or Firefox 2, this reminds me of one of the great cheats of "small applications" developers everywhere:
SetProcessWorkingSetSize(GetCurrentProcess(), -1, -1)
This Windows API makes your application look *very* efficient without actually doing anything, and has been employed by MANY a popularly considered"lightweight" application (and some, um, less light) - because the "Memory Size" column in Task Manager on Windows doesn't reflect memory usage.
"Hunh?!?!", you say?
That column actually reflects the working set of memory for your app - which is the amount of memory currently "realized" (in active use) by your process. Let's look at some use cases to illustrate what that actually means:
1) Allocate a bunch of memory and free it. Your app isn't reserving the memory space, but the working set may still be high - Windows will lazily reclaim if its needed by another application.
2) Minimize all your application windows. This does the equivalent of the Windows API call I listed above, and the memory working set for that application gets *totally* paged out. Then Windows will load back the memory pages as they're accessed - its the equivalent of clearing a cache.
This last is confusing (and illustrates the issue): after SetProcessWorkingSetSize(GetCurrentProcess(), -1, -1), "Memory Size" in Task Manager doesn't reflect what's been "reserved" (allocated) by an application, just what blocks of memory are being/have been actively "touched" since the working set was "cleared".
If all that's confusing, fortunately for you, its easy to boil down to a simple action: Use the "Virtual Memory Size" column in Task Manager instead to look at application memory usage. You can find under the "View... Select Columns..." menu. It reflects what the application has requested from the OS, but not yet released, i.e. the real memory consumed by the application!
More info here.