Discrepancy between what typeperf reports - and every other tool (mem profiler, process explorer, full dump)

232 views Asked by At

Trying to do a before/after comparison of 2 versions of the same .net 3.5 application, I get inconsistent results, depending on what tool I use.

typeperf - which I'd think would be authoritative - says:

  • v1: 244MB / 260MB (private bytes / working set)
  • v2: 281MB / 296MB

Process Explorer shows these figures in the performance graph:

  • v1: 283MB (private bytes)
  • v2: 262MB

So typeperf says v2 got more memory hungry, Process Explorer claims the opposite.

These are all separate measurements and different runs, but the numbers are reproducable astonishingly reliably.

In addition to the 2 aforementioned tools, I also took full memory dumps from Process Explorer, and looking only at the file sizes (haven't had the time to WinDbg or otherwise analyze them yet):

  • v1: 484MB (full dump file size)
  • v2: 480MB

Also, when running the app from .net Memory Profiler, both native memory, .net memory as well as total memory are lower in v2 than in v1.

So it seem it's typeperf against the rest of the world (WinDbg analysis still outstanding).

Who's right, and how would I know?

1

There are 1 answers

0
Evgeniy Berezovsky On BEST ANSWER

I have a good idea what the problem was: In my tests, I did not give GC enough time to do its job.

  • v1 created garbage and kept references to it (-> memory leaks), so there was nothing to clean up
  • but v2 created garbage and released the references.

When taking a full dump or when using the memory profiler, the GC would be run (in the latter case I know it for a fact, in the former I'm guessing, based on private bytes dropping significantly when dumping)

That explains it for me.