What′s New in dotTrace

JetBrains Rider integration 2018.3

In addition to Visual Studio, now dotTrace is a part of the JetBrains Rider IDE on Windows. You can configure and run profiling sessions, get snapshots, and analyze them in the built-in viewer.

.NET process filter 2018.2

Though, this release was mainly focused on improving dotTrace performance, we've also improved profiling of arbitrary .NET processes. Now, when configuring a profiling session, you are able to set an include filter: dotTrace will attach only to a process that matches the filter.

Improved performance 2018.1

The main scope of this dotTrace release was stability and performance improvements.

Support for async calls 2017.3

The downside of asynchronous code is it's extremely difficult to profile and analyze its performance.

dotTrace 2017.3 dramatically simplifies the analysis of asynchronous code. It marks all async call nodes in the Call Tree and groups the corresponding await time and continuation code under that node. This means that you can quickly find all "parts" of an asynchronous call in one place instead of searching in different call stacks.

To learn more, see Analyzing performance of asynchronous .NET code with dotTrace.

Forecasting performance in Timeline Viewer 2017.3

Do you remember the "performance forecasting" feature in the Performance Viewer?

Now, you can do the same thing in the Timeline Viewer. Simply exclude a particular method from the Call Tree, and dotTrace will recalculate the entire snapshot as if there is no such method.

Backtraces in Methods and Subsystems 2017.3

When examining a list of top methods in Methods and Subsystems, it may be helpful to quickly view backtraces (an inverted call tree) of a particular method to identify its origin. Now, you can do this right in Methods and Subsystems without switching to the Call Tree.

Marking user assemblies as system ones 2017.3

Sometimes, you may want dotTrace to treat particular user modules/assemblies as system ones. This may be helpful, for example, in case the user modules provide some core functionality and are not supposed to be optimized.

After you mark a user module as a system module, all rules that are applied to methods from system modules will be applied to methods from this user assembly as well: e.g. the way the methods' time is calculated in Methods and Subsystems and system calls folding.

Navigation path in Call Tree 2017.2

When navigating a call tree, it's always been tough to understand how you ended up at a particular function. Not anymore with dotTrace 2017.2: the Call Tree view shows all your transitions in the left gutter.

Timeline profiling from the command line 2017.2

The command-line profiler finally supports the Timeline profiling type.

It's also worth noting that dotTrace command-line tools are now available as a NuGet package.

Profile running apps with drag and drop 2017.1

You can now attach the profiler to running applications using drag and drop. Simply drop a special icon onto the application window that you want to profile.

Subsystems in Timeline Viewer 2016.3

In 2016.3, Timeline Viewer gets one of the greatest Performance Viewer's features: Subsystems.

The mechanics of Subsystems are quite simple: in most cases, each subsystem just groups calls made within a certain namespace or assembly. It is extremely useful when you need to quickly evaluate how time in a particular call subtree is distributed among various components: user and system code, WPF, LINQ, collections, strings, and more.

Subsystems are very flexible. If you use third-party frameworks in your solution, simply add the corresponding subsystems to dotTrace. Just a quick glance at the call's Subsystems will allow you to understand how much time this call spends in a particular framework.

Analyze native memory allocations 2016.3

dotTrace 2016.3 is able to collect data about memory allocations made to the native heap.

The Native Memory Allocation event filter allows you to see what methods are making the allocations and analyze all issues related to the native memory: potential memory leaks, issues with unmanaged components used by your managed code, and so on.