Trying to determine exactly how much memory an application uses is extremely diificult, requiring voodoo science some would say. Part of the problem is ambiguity in the terminology, as illustrated below.
The
Task Manager help file defines
Memory Usage as the
Working Set for a process, the number of pages
currently present in memory, in KB. It defines
Virtual Memory Size as the amount of virtual memory or address space committed to a process.
Paged Pool is defined as the amount of memory charged to a process that can be moved to the pagefile;
Nonpaged Pool is operating system memory that is never moved to the pagefile. Both are measured in KB.
The
Microsoft Management Console help file defines
Working Set as the current number of physical memory bytes
used by or allocated to a process. The help file goes on to explain that part of that allocation may be located in the pagefile.
However, something is wrong with these definitions. First, notice the contradiction in the definition of
Working Set. Start
Task Manager and look at the
Processes tab; you'll notice some glaring inconsistencies with these definitions. First, if they are correct, then the amount of memory listed for a process'es
Virtual Memory Size would always be greater than or equal to the amount listed for its
Memory Usage, but you'll see many cases where MU exceeds VMS. Second, look at the numbers for
Paged Pool and
Nonpaged Pool. They are all listed in tens or hundreds of KB's, leading me to believe that the figures listed are the amount of memory used by the processes' table entries in the pools, not the actual amount of memory. Notice also that some processes are listed as having 0 KB in both the
Paged and
NonPaged Pools, yet thir
Memory Usage and
Virtual Memory Size are non-zero.
Another big part this problem are the definitions of 'virtual memory' and 'allocated memory.' Seemingly everybody has a different concept of their meanings. First, some say virtual memory is that part of a program's memory allocation that resides in the pagefile, others that it's the sum of the amounts of its physical memory and that saved to disk. The former is conceptually close enough for most discussions, but the latter is the actual truth. Second, most people think allocated memory is the memory that a program is actually using; however, it is the memory that has been made available for it to use, but some of that memory may actually not be in use at a given time, as I'll explain later.
Programs do not work with physical memory; they work with virtual memory. When an application starts, the OS assigns it a virtual address space; the address range is irrelevant, but it's is much larger than the amount of memory the program will ever use. The size of the application's virtual address space is the amount of memory currently allocated by the OS for the program to use. For the remainder of the discussion, I'll use the term 'address space,' but realize that this refers to virtual address space. Also, be aware that the terms 'allocated memory' and 'memory allocation' also refer to memory in the virtual address space.
Based on the requirements specified in the executable, some of that address space is put to use immediately, allocated by the OS from physical memory to load the program executable, core DLL's, and initial program stack and mapped into the address space. It also allocates a memory segment for use as a memory heap. During it's initialization, the program may request more memory, but depending upon the nature of the request(s), some of that memory may be allocated from physical memory and some from the pagefile. (Some programs request more memory than they need, in anticipation of that need -- a performance improving practice carried over from the
DOS and
Windows 3.1 days. There's little to nothing to be gained from this with modern Windows OS's.)
When the program first accesses a portion of its allocated memory that exists only in the pagefile, e.g., to load a DLL for a spell checker or for use as a file I/O buffer, one or more page faults are generated. In response, the OS with the aid of the CPU's memory manager maps the required number of page(s) of physical memory to a portion of the program's address space, making them available to the program and increasing the size of its allocated memory.
An example of a memory allocation that exists only in the pagefile that
avast! users can identify with occurs when an application opens a file for writing, but the
Behavior Blocker intercepts the attempt, and the user denies permission. Memory for an I/O buffer is allocated for the program, but until the I/O operation occurs, it is never used and resides on the hard drive.
Now, consider a user who is surfing the Web and has a dozen windows open, each displaying pages from different web sites. The browser has requested memory to display those pages. Assume for the moment, the user is actively moving between 2 of them, and all the memory used for these windows is located in physical memory. Then, the user responds to a virus database update and starts a thorough scan of the hard drive including archives, and the drive contains a lot of large Zip files. Let's also assume this user has a pitiful machine with only 64 MB of RAM. As
avast! requests and receives more and more memory, increasing the size of its address space, and the amount of free physical memory drops lower and lower, the OS "takes away" some memory from the browser in order to meet the scanner's requirements. Because the OS tracks physical memory usage and is aware that the memory holding 10 of the dozen web pages hasn't been accessed for awhile, it swaps the contents of some of it to the hard drive and maps the physical memory into
avast!'s address space. While the size of
avast!'s memory allocation increases, the size of the browser's doesn't decrease; it gets no smaller, but some of it's contents are now located in the pagefile.
At this point, the user continues surfing the web and clicks a link in a third browser window. Since the contents for this memory are on the hard drive, one or more page faults are generated. At this point, the OS swaps the contents of some of the physical memory used by
avast! to the pagefile replacing it with the contents needed by the browser and maps it into the browser's address space. The memory allocation for both programs remains unchanged, only the location of their contents changes. Meanwhile the on-demand scanner, which is running in the background, tries to access the contents of its memory now held on the hard drive. The OS swaps out the contents of the physical memory that the scanner needs the least and replaces it with the data that it needs now. Again, the size of the address space for both programs remains unchanged.
At this time, the user notices that the virus scan is taking a real long time and closes the windows for the 9 unused web sites, and the browser releases the memory back to the operating system. The size of the browser's address space decreases. The next time the scanner generates a page fault, the OS replaces the contents of that page with the correct page from the hard drive. The browser's memory allocation drops, but the scanner's remains unchanged. But because the browser has released some memory, if
avast! requests more memory to process the biggest Zip file seen so far, the OS allocates it from physical memory -- no swapping required.
So what's the upshot of all this? I can't remember at this point.
Oh, yeah, simply looking at the numbers spit out by Task Manager is not enough. Microsoft's definitions conflict with each other, and the information displayed by Task Manager apparently doesn't always match the definitions, nor does it always make sense. The impact of
avast!'s memory usage is not only determined by the size of its memory allocaton, but how it uses it in conjuction with everything else running on the system. The bottom line question isn't how much memory does
avast! use, but how much does this usage negatively impact your system, and can that impact be reduced? Getting the answers requires a detailed analysis. The Performance Monitor can aid in this quest, and its help file has quite a but of information and advice for going about it.
Regards,
Hornus
