Performance Profiling in Rider 2018.3. What’s New?

Alexey Totin

If you’re an active Rider 2018.3 user or just follow our blog, you probably know that Rider just got an integrated performance profiler based on JetBrains dotTrace. Though we’ve already reviewed the profiler features on the EAP stage, the release version brings some important changes, especially concerning profiling session configuration. Read this post to learn more about the changes.

Supported OSs and frameworks

Just to reiterate: in Rider 2018.3, the profiler supports only Windows + .NET Framework / .NET Core. We’re on the finish line with adding support for Mono and Mono Unity (as well as support for Linux and MacOS), but the feature still requires some polishing. It is highly likely that you will see it in early 2019.1 EAP builds.

What can you profile in Rider?

A quick reminder of what can be a profiling target:

• NET / .NET Core standalone applications
• ASP.NET / ASP.NET Core web applications (IIS Express only)
• Arbitrary .NET / .NET Core processes
• NUnit / xUnit / MSTest unit tests

In this post, we’ll take a quick look at how you can profile apps in Rider. For details on how to profile tests or arbitrary .NET processes, please refer to the Rider documentation. So, what has changed exactly in the release version of Rider 2018.3?

Configuring and starting a profiling session

Session configuration has been affected the most as it is no longer part of run configuration:

• Profiling session configuration is a separate entity that is selected/edited right from the toolbar.
• Profiling target is always an executable specified in the currently selected run configuration. For example, if you profile a web app on IIS Express, the profiling target is iisexpress.exe that runs this web app. Currently, you can profile the following run configuration types:
  • .NET Executable
  • .NET Launch Settings Profile
  • .NET Project
• To start a session, simply select a profiling configuration and click the same control on the toolbar.

Getting snapshots

This part hasn’t changed much since the EAP stage. It’s quite straightforward: after the profiling session starts, do what you need to do in your application, and then click Get Snapshot.

Analyzing snapshots

Once you have a performance snapshot, use the Top Methods view and the Call Tree view to determine the cause of a performance bottleneck. The analysis workflow has changed somewhat after the EAP.

Combined Call Tree and Top Methods

First of all, the Top Methods and Call Tree views are now connected with each other. If Follow the selection is turned on, Top Methods shows methods only for the subtree that is currently selected in Call Tree.

Filters for Timeline snapshots

The second improvement is related to Timeline profiling. We’ve added more filters comparing to the EAP. Now, you can use four basic filters:

• by thread,
• by thread state,
• by method, and
• by subsystem.

Improved navigation

The navigation capabilities are also improved. You can navigate:

• from a snapshot to code,
• from code to a snapshot,
• from Search Everywhere to a snapshot.

As always, we invite you to download the latest Rider to try its new profiling features in practice.

Subscribe to a monthly digest curated from the .NET Tools blog:

Subscribe form

By submitting this form, I agree to the JetBrains Privacy Policy Notification icon

By submitting this form, I agree that JetBrains s.r.o. ("JetBrains") may use my name, email address, and location data to send me newsletters, including commercial communications, and to process my personal data for this purpose. I agree that JetBrains may process said data using third-party services for this purpose in accordance with the JetBrains Privacy Policy. I understand that I can revoke this consent at any time in my profile. In addition, an unsubscribe link is included in each email.

Submit

Thanks, we've got you!