Chapter 19: Smoothing the Working Set

Overview

As the Godzilla movie of a few years ago said, and according to a lot of the spam in your inbox, "size does matter." All developers salivate over bigger and faster machines, but what we really need to be worried about is the size of our binaries. The old adage "small code is good code" still applies in today's world of 512-MB developer machines and 2-GB servers. Just because you have what looks like infinite memory doesn't mean that you have to use it all!

After you've taken care of the obvious performance issues in your code, such as mistakenly calculating pi to a billion digits inside some loop, it's time to ensure that your application's working set is as small as possible. The working set is the amount of memory dedicated to the currently running parts of the program. The smaller you can make the working set, the faster your computer will run because you'll avoid page faults. A page fault occurs when parts of your application are either not in cache memory (soft page faults) or not in memory at all and have to be brought in from the hard disk (hard page faults). As a wise man once told me, "A page fault can ruin your day!"

When you're looking at the Mem Usage column in the Processes tab of Task Manager, you're looking at the current working set of your application. Many other diagnostic and informational tools such as PerfMon also show you the working set. After you've ensured your algorithms are memory frugal, you need to consider the amount of memory taken up by the code itself. I'll start this chapter by discussing the ramifications of page faults when it comes to execution and why these page faults hurt you. As you'd expect, I'll also present a tool, Smooth Working Set (SWS), which will make tuning your working set nearly a snap.