CODEWITHSUNDEEP
visual-studiomemoryprofilingcrtdbg.h
Simpleton
Simpleton

Reputation: 703

Why are results of CRT and VS memory profiling so different?

Traditionally I have used the CRT memory reporting functions like this:

    _CrtMemState state[3];
    _CrtMemCheckpoint(&state[0]);
    foo();
    _CrtMemCheckpoint(&state[1]);
    int const diff = _CrtMemDifference(&state[2], &state[0], &state[1]);
    _CrtMemDumpStatistics(&state[2]);

More recently I have used Visual Studio's builtin heap profiling tool with snapshots. Create first snapshot before foo(), second snapshot after foo(), then look at the diff output.

Now I used both at the same time and compared the results. I expected both results to be pretty much the same, if not exactly the same. But this is not the case. Memory sizes vary wildly. The only thing they share is the number of allocations. I don't know what to make of this. How should I interpret those results? What causes the difference? Whom should I trust?

Note that the CRT results are the same indepedently of heap profiling being enabled or not.

Upvotes: 0

Views: 171

Answers (1)

Simpleton
Simpleton

Reputation: 703

So it seems that memory profiling is neither an exact science nor a very popular one.

Short answer to my own question: Just pick any type of measurement, then stick with it and compare the abstract numbers for every measurement you take. But never start wondering what those numbers could mean.

FYI, here's what I explored:

  • Snapshot diffing by _CrtMemCheckpoint / _CrtMemDifference.
  • In addition _CrtSetAllocHook to track total allocations during the task, because _CrtMemState's lHighWaterCount (peak since app start, not since last snapshot) and lTotalCount (overflows, sometimes weird glitches) are not reliable. Sadly, _CrtSetAllocHook does not enable you to match allocs and de-allocs.
  • GetProcessHeap / HeapSummary to inspect the default process heap.
  • GetProcessMemoryInfo yields similar numbers as HeapSummary, but of course not the same. Occasionally, there's even a large gap between the two. Apparently GetProcessMemoryInfo is also providing the values you see in Windows' TaskManager.

In the end, I used _CrtMemCheckpoint, _CrtMemDifference and _CrtSetAllocHook in debug, because I felt that I could interpret those numbers. However, these functions are not available in release, so I used GetProcessMemoryInfo there. Had no clue how to interpret those numbers, but everytime they went down because of my optimizations, they gave me a happy face.

Upvotes: 0

Related Questions