You may want to get a better understanding of the pieces inside the working set of your application. For example, you might save a lot of code space with the Working Set Tuner only to discover that the code space is only a small portion of your overall working set. In fact, this might even be something you want to do before you go to all the trouble to tune your code.
You probably want to make these measurements on a test computer. Choose a computer large enough to hold your entire working set tuning test scenario in memory. You might need to discover this size through the trial and error process described in this section.
To do this, you can use Virtual Address Dump (VaDump). VaDump looks inside the working set of a process and determines the nature of each page.
Note
Link your application using the -debug and -debugtype:coff options, so you get full use from VaDump.
vadump -o -m -p pid > app.vad
The -o option tells VaDump to monitor the working set in the original style, the -m option tells VaDump to use the mapped symbols, and the -p option indicates the process identifier (pid), in decimal, of the process to measure. In the example command line, the output is directed to the file App.vad. Again, do not press ENTER yet.
The output from VaDump shows the nature of each page in the working set of your process:
0x00010000 PRIVATE Base 0x00010000 0x00020000 PRIVATE Base 0x00020000 0x0012d000 PRIVATE Base 0x00030000 0x0012e000 PRIVATE Base 0x00030000 0x0012f000 PRIVATE Base 0x00030000 0x00130000 PRIVATE Base 0x00130000 0x00140000 PRIVATE Base 0x00140000 0x00141000 Process Heap 0x00142000 Process Heap 0x00143000 Process Heap 0x00240000 PAGEFILE_MAPPED Base 0x00240000 0x00250000 DATAFILE_MAPPED Base 0x00250000 unicode.nls 0x00251000 DATAFILE_MAPPED Base 0x00250000 unicode.nls 0x00253000 DATAFILE_MAPPED Base 0x00250000 unicode.nls 0x00260000 DATAFILE_MAPPED Base 0x00260000 locale.nls 0x00263000 DATAFILE_MAPPED Base 0x00260000 locale.nls 0x00270000 DATAFILE_MAPPED Base 0x00270000 sortkey.nls 0x002c0000 DATAFILE_MAPPED Base 0x002c0000 sorttbls.nls 0x002d0000 PRIVATE Base 0x002d0000 0x002e0000 PAGEFILE_MAPPED Base 0x002e0000 0x002f0000 PRIVATE Base 0x002f0000 0x01000000 menappl.exe (1000) _except_list 0x01001000 menappl.exe ( 165) LogDisplayDlgProc@16 ( 24) GetSystemPerfData@16 ( 1a0) UpdateSystemData@8 ( 1c) MemorySize@4 ( 29) GetObjectDefByTitleIndex@8 ( 14) LogCollecting@4 ( 113) DrawAlerts@8 ( d2) DrawLog@8 ( 4c) SmallFileSizeString@8
The page virtual addresses appear on the left. For each section of address space, the base is shown on the right. PRIVATE pages are dynamic data pages that are private to the process. Process Heap pages are dynamically allocated from the process heap. It can be difficult to determine who is using this space, and you might need to look at pointers within your application using the debugger.
The system pages are those allocated for the page tables and for the working set packing list itself. This might be larger than your application actually needs, because VaDump needs to scan them. So use System Monitor as described to determine the difference. For this example, when we looked at the working set of System Monitor while charting, running VaDump added five pages to the working set.
If COFF symbols are included and the module was linked with the -debug flag, other pages that belong to specific modules are indicated by listing which public symbols occur within the page. This helps you to understand why a particular page has been brought into memory. If the module was compiled without the correct flags, you will see only the module name.
Any pages listed as belonging to the module "Error" are pages that did not resolve to a particular module.
You will also find some DATA pages at the upper end of the application's address space. These are for such system-related items as the Process Environment Block, the Thread Environment Blocks, the Per-Thread Data Area, and so on.
Pages in the range starting at 0xC0000000 are page table pages. They are listed showing the range of pages they map, how many of those are in memory (these are called resident pages), and the range of resident pages and their modules.
Finally, there is a summary of pages and who owns them. These pages summarize the pages already listed, so avoid counting them again.