A few months back I was in a debate about the value of shared code segments between virtual machines. In my view there is no question that shared code across VMs has some value but code is small compared to data so the impact will be visible but not fundamental. What follows is an inventory of a typical client-side systems.
This experiment was done on an IBM T43 laptop with 1GB of memory running Vista RTM, desktop search, Foldershare (it rocks), and Outlook. Outlook was in use prior to and during the measurement. The system has been running for three days since the last boot. The summary stats are:
| Classification |
pages |
Meg |
% |
| Kernel: |
65824 |
257.125 |
25% |
| User: |
195913 |
765.2852 |
75% |
| Total: |
261737 |
1022.41 |
|
| Kernel Pages |
|||
| Kernel Image: |
7395 |
28.88672 |
11% |
| Kernel Pure Data: |
58429 |
228.2383 |
89% |
| Kernel Total: |
65824 |
257.125 |
|
| User Pages |
|||
| User Code: |
32348 |
126.3594 |
17% |
| User Data: |
163565 |
638.9258 |
83% |
| User Total: |
195913 |
765.2852 |
Immediately after boot, 22% of the memory was code which makes sense. As the O/S and apps come up, all constructors and initializers run. After being memory resident for a few days, only those pages currently in use stay loaded and the user code percentage fell to 17%. Ironically, code load time is an issue at start-up time but the actually percentage of code resident in memory over longer runs is fairly small. Vista Superfetch helps with the code load times but, from looking at this data It’s clear that flash memory could make a huge difference to O/S boot and application load times.
The percentage of memory holding code pages is not that high so when going after memory bloat, look first to the data.
–jrh
James Hamilton, Windows Live Platform Services
Bldg RedW-D/2072, One Microsoft Way, Redmond, Washington, 98052
W:+1(425)703-9972 | C:+1(206)910-4692 | H:+1(206)201-1859 | JamesRH@microsoft.com