{"id":8463,"date":"2015-02-23T09:53:00","date_gmt":"2015-02-23T09:53:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/visualstudioalm\/2015\/02\/23\/performance-improvement-when-debugging-net-code-with-visual-studio-2015\/"},"modified":"2022-07-28T01:37:12","modified_gmt":"2022-07-28T09:37:12","slug":"performance-improvement-when-debugging-net-code-with-visual-studio-2015","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/devops\/performance-improvement-when-debugging-net-code-with-visual-studio-2015\/","title":{"rendered":"Performance Improvement When Debugging .NET Code With Visual Studio 2015"},"content":{"rendered":"

Nothing is more frustrating than trying to debug an application that runs significantly slower when you\u2019re debugging it than it does <\/ins>when it runs without a debugger attached. Over the years we\u2019ve received numerous complaints along the lines of \u201cwhen I run my application without the debugger it takes a few seconds to execute a scenario, but with the debugger it can take several minutes.\u201d By far the most common cause is a large number of exceptions being thrown and caught somewhere in the application (we\u2019ll look at why later in the post).<\/p>\n

You can usually work around this issue by reducing the number of exceptions being thrown, but unfortunately if the exceptions are fully contained in a 3rd<\/sup> party library there is nothing you can do other than suffer through a slow debugging experience. So we\u2019re pleased to announce that in Visual Studio 2015 in conjunction with .NET 4.6 (available in [Visual Studio 2015 CTP 6][1]) we significantly reduced the performance overhead when handled<\/em> exceptions occur outside of your code (meaning they are thrown and handled in a module excluded by the debugger\u2019s \u201cJust My Code\u201d (JMC) setting<\/a>). In this post we\u2019ll briefly look at how much this can improve performance, then we\u2019ll talk about what you can expect to see based on this change.<\/p>\n

Example of performance speedup for handled exceptions<\/h3>\n

First, let\u2019s look at what this means in practical terms. I created an application<\/a> that will throw and catch the number of exceptions I instruct it to before completing the method call. First, let\u2019s look at how long it takes for the debugger to run the method when 100 exceptions are thrown and handled (also referred to as \u201cfirst chance exceptions\u201d)<\/p>\n

\"clip_image002\"<\/p>\n

Note: I\u2019m using a *StopWatch<\/em><\/a><\/em> to record the time and have displayed it by *pinning the DataTip to the editor<\/em><\/a>**<\/p>\n

Notice that it took ~813ms seconds to execute a method that did nothing other than throw and catch 100 exceptions with the debugger attached. Next, to simulate this code running in an external library, I\u2019ll tell the debugger this isn\u2019t user code by adding a DebuggerNonUserCode<\/a> attribute to the ClassWithInternalExceptions<\/em> definition. Running it again yields a time of ~26ms meaning it ran ~97% faster!<\/p>\n

\"clip_image004\"<\/p>\n

Marking the code as non-user on VS versions prior to VS2015 (or with a .NET Framework prior to 4.6) will not provide any savings and you still have to suffer though the slow performance.<\/p>\n

A peek under the hood<\/h3>\n

To understand the reasons behind the performance gains, it\u2019s important to understand how exceptions work when a debugger is attached to a .NET process. When an exception is thrown (even if it will be handled) the runtime pauses the process to send a notification to the debugger so it has the opportunity to stop on the throw if you have enabled this in your exception settings<\/a>; if not, the debugger resumes the process. As you can see, it doesn\u2019t take many exception events to significantly impact the performance of your application when debugging. There are a few factors that contribute to the exact performance overhead including the number of threads in the process and the depth of the call stack where the exception occurs, but in both cases more will mean higher overhead. However, regardless of your exception settings, when Just My Code is enabled the debugger will never break for an exception that is thrown and handled in non-user code. Meaning you were paying a performance penalty that would yield little benefit, so we fixed it!<\/p>\n

Feel free to download the attached project<\/a> and experiment with the performance impact of exceptions in various scenarios including stack depth and the number of threads in the process.<\/p>\n

Notable points<\/h3>\n

There are a few things to note about how this change works.<\/p>\n