> Now, let's say that the memory in use (the 256K) is spread out through
> your application's address space so that only one byte per 4K page is
> used. Each time your application accesses a byte, the entire page must
> be available ("swapped in" if it isn't already). Your application, from
> the operating system's point of view, needs: 256K bytes in use (256K
> pages in use) * 4096 bytes per page = 1G of memory for the working set!
> It may sound like a rediculous situation but it does in fact happen;
> it's typically called "heap fragmentation".
Nice explanation. I'm starting to get this now. (I think)
> You will need to determine *why* there is so much swapping (e.g.
> tracking some key counters using Performance Monitor) *before* trying to
> eliminate the problem (e.g. calling SetProcessWorkingSetSize).
Damn! Thought this might be a quick and painless solution. Would a profiler
help in this situation?
> The list of counters I provided give you the perspective of the
> operating system and are a good starting point. None of those counters
> should increase over long periods of time.
Ok thanks for that. My early testing shows no increase in those counters but
the testing has been limited.
