Red Gate forums: ANTS Memory Profiler 7 EAP

RE: WP7 Profiling

melvyn.harbour — Wed, 23 Mar 2011 10:23:12 GMT

Some time yet I'm afraid. The .NET profiling API doesn't exist on phones, so we need to attack it from a different angle, and there's a fair amount of groundwork we need to do before you'd be able to see anything usable.

Mel

WP7 Profiling

paulh — Wed, 23 Mar 2011 08:07:03 GMT

I notice that WP7 profiling is on the roadmap - any idea when this will make it into the EAP?

RE: Thrown exceptions when starting to profile

sadmemories20 — Tue, 08 Mar 2011 09:37:55 GMT

Mediathrall wrote:

When attempting to start a memory profile with my ASP.NET MVC application, I'm spammed with the following exceptions:

Exception Processing Message c0000013 Parameters 75b6bf7c 4 75b6bf7c 75b6bf7c

These exceptions occur right after the browser window opens to launch the application, and spam infinitely, making it impossible to use the memory profiler. The performance profiler works fine (it throws a single exception when profiling begins, but then continues normally).

Attempting to start a memory profile after the application has already started results in the same exceptions. Help?

Thank you so much for the post. It's really informative!

__________________
watch online movies

Thrown exceptions when starting to profile

Mediathrall — Sun, 06 Feb 2011 05:35:31 GMT

ANTS Memory Profiler 7 EAP Build 667 released

AndrewH — Wed, 05 Jan 2011 16:39:16 GMT

We're pleased to present the next Early Access Build of our forthcoming ANTS Memory Profiler 7, which you can download from here http://downloads.red-gate.com/ANTSProfiler/EAP/ANTSMemoryProfiler_7.0.0.667.exe. As usual, this build will expire after 14 days.

We are planning a number of new features for Memory Profiler 7, and this preview demonstrates a few of them:

� New 'Categorized references' view in the Class Reference Explorer.
This view groups instances of the class according to their shortest path to a GC Root. It is therefore easier to find out at a glance what is holding your the most objects in memory. If you prefer to see the full picture, the old Class Reference Explorer is still available - just switch to the 'All references' view.

� New 'Survivors in growing classes' filter.
Until now, finding a leak in objects that survived between snapshots was not easy. This new filter shows the classes which have more instances in the current snapshot than in the baseline snapshot, and then shows only the surviving objects from those classes.

� Take snapshots at exactly the right moment by calling them from within your code.
We've had so many requests for this feature, we're sure that you'll be delighted that this is now possible. Simply link to the RedGate.MemoryProfiler.Snapshot DLL and call RedGate.MemoryProfiler.Snapshot.TakeSnapshot(). You can name your snapshot by providing a string argument to TakeSnapshot().

� Completely redesigned summary screen

� Improved support for applications using WPF.

Please send us your feedback about the EAP in this forum: What do / don't you like? Have you found any issues with using the tool? What would you like us to add next? We read and value all of your comments.

If you should encounter any problems, please click the 'Send to Red Gate' button so that we can correct the fault in time for the release.

RE: ANTS Memory Profiler 7 EAP Build 656 Released

melvyn.harbour — Wed, 05 Jan 2011 11:09:12 GMT

Creating a process that allows people to fully automate the memory profiling and analysis process to allow automated QA of memory related issues is certainly something we've been looking into. The API is obviously a first step in that direction. We need to do a substantial amount more thinking and research in order to understand exactly the use-cases, and how we can best design ANTS to help people in this regard. If you don't mind, I'll pass your details on to our Product Management team, who may well be interested in speaking to you further to understand exactly how you'd like to be able to use the system.

Mel

RE: ANTS Memory Profiler 7 EAP Build 656 Released

rs — Wed, 05 Jan 2011 10:08:18 GMT

We've been getting superb results using the API. We've got a pretty complex modular Wpf application and the profiling we are doing is designed to identify memory leak scenarios.

As you may or may not know, there are several nasty Wpf "gotchas" that you start to encounter when you build more complex Wpf applications that don't have a static set of Ui elements. BitmapImageSource objects that aren't frozen, dynamic resource references to other non frozen resources, actions in styles on visuals that are never made visible and some really nasty issues with merged resource dictionaries all keep Wpf objects (and their related viewmodel/model items) alive. Although not necessarily simple to fix, the memory profiler is making these issues easy to identify and importantly is giving us a framework for the future to spot these as part of the normal development process.

The process for us to identifying memory leaks is to: a) establish a scenario that should not hold any memory once complete and can be executed multiple times b) execute it once (this ensures that configuration / common model objects that are loaded once don't cloud the results) c) take a base snapshot d) repeat the operation multiple times e) take a final snapshot. When comparing the base snapshot and the final snapshot the leaks tend to stick out like a sore thumb - a shortcut that often works is to look for differential instance counts matching the number of times the process executed and then use the instance graph to figure out what is keeping the object tree alive.

For the process above to be automated and therefore work reliably (and, critically, to be repeatable later in the development cycle) the snapshot API was essential. One thing we have found necessary is to run multiple GC.Collect() calls in our code - I suspect that Wpf / our object model requires multiple garbage collection cycles to flush out unused objects from complex trees. Not sure if this is something practical to build in to the memory profiler (the ability to run multiple GC cycles until there is no further movement), but if it was that would be handy and make the snapshots cleaner.

Having got this far, the one thing we are now trying to figure out is how to fully automate this testing in a similar way to our TFS test suite. At present the test execution if fully automated (aside from running up the profiler) but we need to manually examine the snapshots once it's complete. I'm assuming this doesn't already existing already, but if there was a way to programmatically examine the instance difference counts (for items with source items only as an option) between 2 snapshots then we would have the potential to roll this process up into a unit / integration test suite that could run every build - now that would be a huge step forward for QA automation and another move towards really reliable continuous integration.[/list]

RE: ANTS Memory Profiler 7 EAP Build 656 Released

melvyn.harbour — Wed, 05 Jan 2011 09:11:47 GMT

New EA build will be out a bit later today. This should be the last EA build before release.

How have you been getting on with the snapshot API? Any comments, criticisms or suggestions?

Mel

RE: ANTS Memory Profiler 7 EAP Build 656 Released

rs — Tue, 04 Jan 2011 17:23:55 GMT

We've been hammering the EAP pretty hard but today it's expired! Please could we get an updated release - we're doing some profiling work that we can only do with the snapshot API. Thanks.

ANTS Memory Profiler 7 EAP Build 656 Released

melvyn.harbour — Wed, 22 Dec 2010 14:37:00 GMT

We're pleased to present the latest Early Access Build of our forthcoming ANTS Memory Profiler 7, which you can download from here http://downloads.red-gate.com/ANTSProfiler/EAP/ANTSMemoryProfiler_7.0.0.656.exe. As usual, this build will expire after 14 days.

We are planning a number of new features for Memory Profiler 7, and this preview demonstrates a few of them:

� New 'Categorized references' view in the Class Reference Explorer.
This view groups instances of the class according to their shortest path to a GC Root. It is therefore easier to find out at a glance what is holding your the most objects in memory. If you prefer to see the full picture, the old Class Reference Explorer is still available - just switch to the 'All references' view.

� New 'Survivors in growing classes' filter.
Until now, finding a leak in objects that survived between snapshots was not easy. This new filter shows the classes which have more instances in the current snapshot than in the baseline snapshot, and then shows only the surviving objects from those classes.

� Take snapshots at exactly the right moment by calling them from within your code.
We've had so many requests for this feature, we're sure that you'll be delighted that this is now possible. Simply link to the RedGate.MemoryProfiler.Snapshot DLL and call RedGate.MemoryProfiler.Snapshot.TakeSnapshot(). You can name your snapshot by providing a string argument to TakeSnapshot().

� Completely redesigned summary screen

� Improved support for applications using WPF.

Please send us your feedback about the EAP in this forum: What do / don't you like? Have you found any issues with using the tool? What would you like us to add next? We read and value all of your comments.

If you should encounter any problems, please click the 'Send to Red Gate' button so that we can correct the fault in time for the release.

Mel

RE: Snapshots very slow during "Filling Cache"

Cheetah — Fri, 10 Dec 2010 21:15:09 GMT

That fixed it, thank you

RE: Snapshots very slow during "Filling Cache"

AndrewH — Fri, 10 Dec 2010 17:09:40 GMT

Hmm, I think I might know why that's happening: the profiler is reading the field values for all of the objects while it's searching for the names of dependency properties. I think I've fixed this behaviour now. Can you try build 649, which should be up at http://downloads.red-gate.com/ANTSProfiler/EAP/ANTSMemoryProfiler_7.0.0.649.exe and see if it still suffers from this issue?

RE: Snapshots very slow during "Filling Cache"

Cheetah — Fri, 10 Dec 2010 15:18:26 GMT

I just tried with the latest build, and the step it sticks on is "Filling object graph"

I tried with a very small console app, and it did not exhibit the slowness.

I tried with a medium size (compared to the first app) WPF app, and it too sat for a bit on the "Filling object graph", but not for anywhere near as long.

In case this is just an issue of scale, the "big" application I started with, once it does finish taking and loading the snapshot, it shows 5710 classes and 14061 instances. Saving the results with just that one snapshot results in a 222 MB file.

RE: Snapshots very slow during "Filling Cache"

AndrewH — Fri, 10 Dec 2010 10:43:23 GMT

We haven't been able to reproduce this here: with our tests, ANTS 7 doesn't seem to be any slower than ANTS 6 and is faster in many cases.

The 'filling cache' stage is really just the message that ANTS displays before moving on to doing some real work (which will display a different message), so this is probably a sign that something has stalled somewhere.

The latest build (634) has been changed so that it displays a specific message instead of the 'Filling Cache' message: could you try it out and see what it's displaying when it gets stuck?

RE: Snapshots very slow during "Filling Cache"

Cheetah — Tue, 30 Nov 2010 16:14:37 GMT

Taking a snapshot with V6 takes about 5 seconds. Assuming that the messages displayed by the profiler while it takes and analyzes the snapshot have roughly the same meaning between V6 and V7, nearly all the extra time taken by V7 is in that "Filling Cache" step.

I should also note that the app being profiled continues running during that filling cache step, and some (but not all) of the ANTS UI remains responsive. For example, I can zoom the counters strip in and out, but I cannot scroll it left / right. I can also take another snapshot while the Filling Cache step runs.

As far as slowdown to the app being profiled, neither V6 nor V7 causes a noticeable slowdown. However, the problem I'm debugging now doesn't involve any of the CPU intensive parts of the app, so a for a slowdown to be noticeable, it would have to be severe enough to impact basic UI responsiveness.