The Relationship between Memory Size and Performance
January 29th, 2008
One can easily spot an application’s memory usage in Windows using Task Manager. However, the numbers shown are often misintepreted and a frustration source of mine when I am bugged by some “professionals” with perfect misunderstandings.
Memory usage has a formal name called “working set size”. A working set is the physical memory allocated by Windows Virtual Memory Manager (VMM) for a process. As a result, if one reads the book Windows Internals and stops here, he will start complaining a program is “fatty and slow” when he sees big working set. Let’s read a bit further before convicting anything. A working set contains two parts: private working set and shared working set. Private working set is used only by the owning process, while shared working set is shared among processes. As a result, we should use private working set size as the standard of judgement, which one can use tools like Process Explorer to inspect.
However, the size of private working set could be deceiving. Windows SDK provides an API named SetProcessWorkingSetSize, which allows developers to force Windows VMM to swap all pagable pages, and eventually lower the number of private working set. The pitfall about the relationship between memory size and performance is that people believe smaller memory footprint implies faster execution and better performance. This is an over-simplified corollary. The actual performance killer is page fault, not memory usage. Programs with higher memory usage have higher probability of page faults. A program runs the best if all memory it demands is loaded, even if the size is huge. Many programs try to satisfy the “perceptual performance” based on this common pitfall and use SetProcessWorkingSetSize to beautify the numbers. From real performance point of view, this is actually not optimal because the use of SetProcessWorkingSetSize invites page faults.
Working set size is a good reference but it is not directly related to the real performance of an application. The real killer is page fault, especially when it is caused by memory leaks. Developers care about working set size because it’s the perfect indicator of memory leaks. Moreover, page fault is just one factor that affects performance, and there are many others to explore and tune.
Windows itself actually call SetWorkingSetSize for programs, provided that the target program has a window and the window is minimized. I guess this is based on a pessimistic philosophy that most programs do not free unused pages right away, so Windows does it for them to boost performance. This interesting behavior actually introduces a very counter-intuitive phenomenon. When people found that the computer is slow, their first reaction is typically minimize all the windows on the desktop except the one they are working on. Doing so forces the SetWorkingSetSize calls and incurs more swapping, which slows down the system further.
|
Comments
