3

C++ native code running on Windows 7. VS2008.

A particular state change on my application increases the working set (private working set) from 16Mb(6.5Mb) to 38Mb(22Mb). As this seemed excessive I examined the heap change using umdh. The difference between the heap before and after I find an increase of ~9Mb.

What accounts for the additional memory in the working set?

I suspect it might be dll loading, but how can I confirm this and break it down?

Downward Facing God
  • 440
  • 4
  • 10
  • Windows does its memory accounting in pages; i.e. 38 MB is really 9500 pages. Is the heap use expressed the same, i.e. 2250 pages? Or is it the sum of the requested allocation sizes? – MSalters May 19 '11 at 11:18
  • It is the byte sum of the requested allocation size. umdh reports "Total increase == 5601391 requested + 3685785 overhead = 9287176" – Downward Facing God May 20 '11 at 08:22
  • The private working set is the size of the heap plus the size of the stack. Are you spawning any additional threads? – Thomas Minor Jun 02 '11 at 00:02
  • Yes, there are multiple threads in the application. I know that each thread is allocated a 1 mb stack, but I think that in practice it is a 4kb stack, with markers to allow it grow, i.e spawning a new thread doesn't add the full 1mb. – Downward Facing God Jun 20 '11 at 13:01

1 Answers1

0

When an application requests memory windows gives it much more than it asks for so that subsequent request from all apps does not result in excessive fragmentation. For example you ask for 1 byte at a time your working set will not grow 1 byte at a time or by page at a shot but could be by megabytes at a shot. Working set are the pages in physical memory. Also windows can take the excess away from you if something else needs it.

MartyTPS
  • 530
  • 2
  • 5
  • I would assume that is the overhead in heap allocation that umdh is reporting. I am asking what the difference between the 9mb heap (including ~4mb of overhead) and the working set increase of 22mb is. – Downward Facing God Nov 04 '11 at 14:24