Comments
4 comments
-
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. -
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 -
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] -
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
Add comment
Please sign in to leave a comment.
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