Forum Discussion

MartinB_1's avatar
MartinB_1
Occasional Contributor
14 years ago

How can I speed up the ALlocation Profiler for native VC++ apps?

Today, I (sucessfully) tried to use AQTime's Allocation Profiler to find some memory leaks in my VC++/MFC Application.



The memory leaks were already highlighted by the leak detection built into MSCRT, but this leak detection doesn't tell you *where* the leak was, so is only useful in scenarios with 100% allocation-order reproducibility as it lists the allocation number.



So I fired up AQTime Pro 7 and set up the Allocation Profiler for the exe + 1 dll + msvcr80.dll



It worked out in the end, but is was so god-awfully slow that it seems of extremely limited use.



This is a heavily multithreaded MFC desktop application. In the tests I did, it normally starts up in about 10 second and then runs with nearly no performance impact on my machine.



When run under the Allocation Profiler, startup took about 5 minutes (!) and you could not use the app (GUI very unresponsive). Closing it (clicking on the ) worked with a delay of multiple seconds and after several minutes more I had my reports, luckily highlighting the offending call stacks.



Obviously, if I had needed to actually *do* anything within my app or if my app wouldn't just idle around w/o the Allocation Profiler, I expect it to never have finished.



How can I speed up the Allocation Profiler for a native VC++ app if all I want to do is find memory leaks?

7 Replies

  • Hello Martin,


    The performance of AQtime and of the profiled application depends on the number of elements traced by AQtime. In case of the Allocation profiler, the traced elements are classes specified by the profiling areas.

    Please disable the default Full Check area, create a new including class level area and add a few classes from your application's modules for testing purposes. Does this help?

  • MartinB_1's avatar
    MartinB_1
    Occasional Contributor
    Thanks for the tip.



    Unfortunately, this was a case of "WTF, I just checked out the source tree and now I'm seeing memory leaks (as reported my MS CRT)" so I really had no clue where the leak came from and had to include everything.



    Maybe I misunderstood something about the allocation profiler: There's quite a lot of memory (still) managed by malloc/free in this application -- will leaks from these calls also be detected by AQTime Allocation profiler?



    cheers,

    Martin
  • MartinB_1's avatar
    MartinB_1
    Occasional Contributor
    Alexei - thanks for the links.



    I had already skimmed these help topics. I'm just confused that I should need to specify a (C++) class to detect malloc leaks, or asked another way - what "areas" do I need to add to detect malloc leaks? (in addition to leaks from class objects?)



    cheers,

    Martin
  • Hello Martin,


    AQtime always traces calls to the run-time memory management functions. That is, you do not need to create a special area to detect such memory leaks. So, in your case, I think, a preferable way to reduce the number of checked leaks is to leave the Full Check area enabled and to create an excluding class level area. The area should contain the majority of your application's classes to make the profiling performance acceptable.

    Here is the list of the traced run-time memory management functions: new, delete, new[], delete[], malloc, calloc, realloc, expand, free. The corresponding memory leaks are reported as  "C++ native memory" in the Report panel.

  • MartinB_1's avatar
    MartinB_1
    Occasional Contributor
    Ah! I didn't think of manually setting up an exclude area!



    One thing more: Would it be possible to set up inclusion/exclusion areas so that only leaks from new/delete are checked but malloc/free is ignored (or vice versa) ?
  • Martin,


    No, currently, there is no way to do this. I have registered your request, though.