Hornus, thanks for the nice reading… again.
I have a couple of comments

(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.)

I don’t quite agree - in many cases it is really advantegous to grab a bigger piece of memory at once, and then use a custom sub-allocator to partition it into actual memory blocks. That’s because the system allocator is of course as generic as possible, providing poor performance in certain situations where a simple custom allocator would in fact provide a big performance boost. Look at the behavior of many server-based apps - they allocate huge memory blocks at startup, and it’s (usually) really for a good reason. The extreme example of this is the MS SQL Server which (by default) almost always takes about 85% of free RAM at once on startup ( even if your machine had 4G of RAM, SQL would grab about 3.5G at startup).

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.

Well in fact the EXE images are implemented via memory-mapped files, not ordinary buffer reads. Thus no buffers need to be preallocated (but virual address space need to be reserved [not commited] of course).

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.

I absolutely agree with this. Memory usage is just one (and probably not the most important) parameter that needs to be considering when rating the performance of a program. But since excessive paging can really have catastrophic consequences in terms of overall system responsiveness (as MS said, ‘A page fault can ruin your day’ :)), the system, in conjunction with reasonably designed applications, is trying to prevent it as much as possible in most of the cases.


Anyway, I wanted to say that we’ve changed some allocation patterns in the upcoming avast update - check out the Mem Usage column as soon as you get the update… (can’t tell exactly when it is gonna be released though) :slight_smile:

Vlk