Typical Profiling Workflow
Your workflow in dotMemory may vary depending on the issue you want to analyze. Nevertheless, generally, it will always include the following steps:
Run a dotMemory profiling session (period of time during which dotMemory measures different aspects of the app). This runs the app you profile as well.
Work with your app for some time as you would normally do. If you seek for a certain memory issue, reproduce the issue in the app.
Get a memory snapshot (an instant image of the managed heap).
For more information about memory usage, you may also get more snapshots (for example, before and after reproducing the issue). dotMemory will allow you to compare these snapshots and understand how your app utilizes memory over time.
Analyze the snapshot(s) to determine the cause of the issue.
Example
How it will look like in real life? For example, your app has a memory leak. Your task is to determine what objects cause the leak and where these objects origin from (an exact call). Simply follow the workflow:
Run a profiling session.
At some point of working with the app, take a memory snapshot.
Work with the app for some time, so that the leak could reveal itself more obviously.
Take a memory snapshot again.
Using a number of dotMemory views, analyze the snapshots and determine:
Objects of what type grow over time?
What prevents these objects from being collected?
What method originates the leak?
If you worked with other memory profilers once, you see that dotMemory doesn't stand out of the row and its workflow is quite similar to others. What really makes dotMemory different is the way you analyze the memory snapshot. For more information, refer to the next section.