views:

304

answers:

3

A colleague has been trying to reduce the memory footprint of a 32 bit app running on vista 64 and has noticed some weird behaviour in the reported size of the private working set.

He made some changes and recompiled the app. Then he ran the app and loaded in a data file. The task manager reports that private working set is 98Mb. He then simply renamed the app to 'fred.exe' now when he runs fred.exe and loads the same data file the private working set is reported to be 125Mb. Rename the file back to its original name, repeat and the private working set is back to 98Mb.

Does anyone know what causes this?

+1  A: 

This usually happens during full moons.

Did he remember to sacrifice a chicken to Ba'al-ze-Bool, the god of memory?

Assaf Lavie
Apparently he's sacrificed his first born. I did tell him that one of the sysadmins kids would suffice.
lilburne
+1  A: 

Vista is doing some smart stuff with application caching (SuperFetch). As I understand it, this is done by application name.

In your case, I'm assuming Vista detected that "originalName.EXE" never benefitted from a large working set, so trimming it to 98 MB helps other apps. The new "fred.exe" on the other hand still gets the default treatment.

MSalters
A: 

The "working set" of an application is (roughly) how much of the application's virtual memory space is currently available to be used. This value fluctuates for many reasons depending on what else is going on in the machine, and does not really reflect the actual memory footprint of the process. It certainly doesn't depend on the name of the executable.

On the other hand, the "private bytes" value is the most useful in measuring the memory footprint of an application. This value reflect the total amount of requests made by the application to allocate more memory, and is not dependent on how much of the application's working set happens to be swapped in at the time.

Greg Hewgill