{"id":973,"date":"2013-04-04T08:54:00","date_gmt":"2013-04-04T08:54:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/dotnet\/2013\/04\/04\/net-memory-allocation-profiling-with-visual-studio-2012\/"},"modified":"2021-10-04T12:36:04","modified_gmt":"2021-10-04T19:36:04","slug":"net-memory-allocation-profiling-with-visual-studio-2012","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/dotnet\/net-memory-allocation-profiling-with-visual-studio-2012\/","title":{"rendered":".NET Memory Allocation Profiling with Visual Studio 2012"},"content":{"rendered":"
\n

This post was written by Stephen Toub, a frequent contributor to the Parallel Programming in .NET blog<\/a>. He shows us how Visual Studio 2012 and an attention to detail can help you discover unnecessary allocations in your app that can prevent it from achieving higher performance. <\/em><\/p>\n<\/blockquote>\n

Visual Studio 2012 has a wealth of valuable functionality, so much so that I periodically hear developers that already use Visual Studio asking for a feature the IDE already has and that they\u2019ve just never discovered. Other times, I hear developers asking about a specific feature, thinking it\u2019s meant for one purpose, not realizing it\u2019s really intended for another.<\/p>\n

Both of these cases apply to Visual Studio\u2019s .NET memory allocation profiler<\/a>. Many developers that could benefit from it don\u2019t know it exists, and other developers have an incorrect expectation for its purpose. This is unfortunate, as the feature can provide a lot of value for particular scenarios; many developers will benefit from understanding first that it exists, and second the intended scenarios for its use.<\/p>\n

Why memory profiling?<\/h3>\n

When it comes to .NET and memory analysis, there are two primary reasons one would want to use a diagnostics tool:<\/p>\n

    \n
  1. To discover memory leaks. <\/b>Leaks on a garbage-collecting runtime like the CLR manifest differently than do leaks in a non-garbage-collected environment, such as in code written in C\/C++. A leak in the latter typically occurs due to the developer not manually freeing some memory that was previously allocated. In a garbage collected environment, however, manually freeing memory isn\u2019t required, as that\u2019s the duty of the garbage collector<\/a> (GC). However, the GC can only release memory that is provably no longer being used, meaning as long as there are no rooted references to the memory. Leaks in .NET code manifest then when some memory that should have been collected is incorrectly still rooted, e.g. a reference to the object occurs in an event handler registered with a static event. A good memory analysis tool might help you to find such leaks, such as by allowing you to take snapshots of the process at two different points and then comparing those snapshots to see which objects stuck around for the second point, and more importantly, why.<\/li>\n
  2. To discover unnecessary allocations.<\/b> In .NET, allocation is often quite cheap. This cost is deceptive, however, as there are more costs later when the GC needs to clean up. The more memory that gets allocated, the more frequently the GC will need to run, and typically the more objects that survive collections, the more work the GC needs to do when it runs to determine which objects are no longer reachable. Thus, the more allocations a program does, the higher the GC costs will be. These GC costs are often negligible to the program\u2019s performance profile, but for certain kinds of apps, especially those on servers that require high-throughput operation, these costs can add up quickly and make a noticeable impact to the performance of the app. As such, a good memory analysis tool might help you to understand all of the allocation being done by the program, in order to help spot allocations you can potentially avoid.<\/li>\n<\/ol>\n

    The .NET memory profiler included in Visual Studio 2012 (Professional and higher versions) was designed primarily to address the latter case of helping to discover unnecessary allocations, and it\u2019s quite useful towards that goal, as the rest of this post will explore. The tool is not tuned for the former case of finding and fixing memory leaks, though this is an area the Visual Studio diagnostics team is looking to address in depth for the future (you can see such an experience for JavaScript<\/a> that was added to Visual Studio as part of VS2012.1<\/a>). While the tool today does have an advanced option to track when objects are collected<\/a>, it doesn\u2019t help you to understand why objects weren\u2019t collected or why they were held onto longer than was expected.<\/p>\n

    There are also other useful tools in this space. The downloadable PerfView<\/a> tool<\/a> doesn\u2019t provide as user-friendly an interface as does the .NET memory profiler in Visual Studio 2012, but it is a very powerful tool that supports both tasks of finding memory leaks and discovering unnecessary allocations. It also supports profiling Windows Store apps, which the .NET memory allocation profiler in Visual Studio 2012 does not currently support as of the writing of this post.<\/p>\n

    Example to be optimized<\/h3>\n

    To better understand the memory profiler\u2019s role and how it can help, let\u2019s walk through an example. We\u2019ll start with the core method that we\u2019ll be looking to optimize (in a real-world case, you\u2019d likely be analyzing your whole application and narrowing in on the particular offending areas, but for the purpose of this example, we\u2019ll keep this constrained):<\/p>\n

    \n
    \n
    public<\/span> static<\/span> async Task<T> WithCancellation1<T>(this<\/span> Task<T> task, CancellationToken cancellationToken)\n{\n    var tcs = new<\/span> TaskCompletionSource<bool<\/span>>();\n    using<\/span> (cancellationToken.Register(() => tcs.TrySetResult(true<\/span>)))\n    if<\/span> (task != await Task.WhenAny(task, tcs.Task))\n        throw<\/span> new<\/span> OperationCanceledException(cancellationToken);\n    return<\/span> await task;\n}<\/pre>\n<\/blockquote><\/div>\n
    The purpose of this small method is to enable code to await a task in a cancelable manner, meaning that regardless of whether the task has completed, the developer wants to be able to stop waiting for it. Instead of writing code like:<\/p>\n
    \n
    T result = await someTask;<\/pre>\n<\/blockquote>\n
    the developer would write:<\/p>\n
    \n
    T result = await someTask.WithCancellation1(token);<\/pre>\n<\/blockquote>\n
    and if cancellation is requested on the relevant CancellationToken before the task completes, an OperationCanceledException will be thrown. This is achieved in WithCancellation1 by wrapping the original task in an async method. The method creates a second task that will complete when cancellation is requested (by Registering a call to TrySetResult with the CancellationToken), and then uses Task.WhenAny to wait for either the original task or the cancellation task to complete. As soon as either does, the async method completes, either by throwing a cancellation exception if the cancellation task completed first, or by propagating the outcome of the original task by awaiting it. (For more details, see the blog post \u201cHow do I cancel non-cancelable async operations?<\/a>\u201d)<\/p>\n
    To understand the allocations involved in this method, we\u2019ll use a small harness method:<\/p>\n
     <\/p>\n
    \n
    using<\/span> System;\nusing<\/span> System.Threading;\nusing<\/span> System.Threading.Tasks;\n \nclass<\/span> Harness\n{\n    static<\/span> void<\/span> Main() \n     { \n         Console.ReadLine(); \/\/ wait until profiler attaches<\/span>\n         TestAsync().Wait(); \n     }\n    static<\/span> async Task TestAsync()\n    {\n        var token = CancellationToken.None;\n        for<\/span>(int<\/span> i=0; i<100000; i++)\n            await Task.FromResult(42).WithCancellation1(token);\n    }\n}\n \n\nstatic<\/span> class<\/span> Extensions\n{\n    public<\/span> static<\/span> async Task<T> WithCancellation1<T>(\n    this<\/span> Task<T> task, CancellationToken cancellationToken)\n    {\n        var tcs = new<\/span> TaskCompletionSource<bool<\/span>>();\n        using<\/span> (cancellationToken.Register(() => tcs.TrySetResult(true<\/span>)))\n            if<\/span> (task != await Task.WhenAny(task, tcs.Task))\n                throw<\/span> new<\/span> OperationCanceledException(cancellationToken);\n        return<\/span> await task;\n    }\n}<\/pre>\n<\/blockquote>\n
    The TestAsync method will iterate 100,000 times. Each time, it creates a new task, invokes the WithCancellation1 on it, and awaits the result of that WithCancellation1 call. This await will complete synchronously, as the task created by Task.FromResult is returned in an already completed state, and the WithCancellation1 method itself doesn\u2019t introduce any additional asynchrony such that the task it returns will complete synchronously as well.<\/p>\n
    Running the .NET memory allocation profiler<\/h3>\n
    To start the memory allocation profiler, in Visual Studio go to the Analyze menu and select \u201cLaunch Performance Wizard\u2026\u201d. This will open a dialog like the following:<\/p>\n
    \"image\"<\/p>\n
    Choose \u201c.NET memory allocation (sampling)\u201d, click Next twice, followed by Finish (if this is the first time you\u2019ve used the profiler since you logged into Windows, you\u2019ll need to accept the elevation prompt so the profiler can start). At that point, the application will be launched and the profiler will start monitoring it for allocations (the harness code above also requires that you press \u2018Enter\u2019, in order to ensure the profiler has attached by the time the program starts the real test). When the app completes, or when you manually choose to stop profiling, the profiler will load symbols and will start analyzing the trace. That\u2019s a good time to go and get yourself a cup of coffee, or lunch, as depending on how many allocations occurred, the tool can take a while to do this analysis.<\/p>\n
    When the analysis completes, we\u2019re presented with a summary of the allocations that occurred, including highlighting the functions that allocated the most memory, the types that resulted in the most memory allocated, and the types with the most instances allocated:<\/p>\n
    \"image\"<\/p>\n
    From there, we can drill in further, by looking at the allocations summary (choose \u201cAllocation\u201d from the \u201cCurrent View\u201d dropdown):<\/p>\n
    \"image\"<\/p>\n
    Here, we get to see a row for each type that was allocated, with the columns showing information about how many allocations were tracked, how much space was associated with those allocations, and what percentage of allocations mapped back to that type. We can also expand an entry to see the stack of method calls that resulted in these allocations:<\/p>\n
    \"image\"<\/p>\n
    By selecting the \u201cFunctions\u201d view, we can get a different pivot on this data, highlighting which functions allocated the most objects and bytes:<\/p>\n
    \"image\"<\/p>\n
    Interpreting and acting on the profiling results<\/h3>\n
    With this capability, we can analyze our example\u2019s results. First, we can see that there\u2019s a substantial number of allocations here, which might be surprising. After all, in our example we were using WithCancellation1 with a task that was already completed, which means there should have been very little work to do (with the task already done, there is nothing to cancel), and yet from the above trace we can see that each iteration of our example is resulting in:<\/p>\n