As you may already know, starting with ReSharper 9 all our .NET products share a common platform (including ReSharper, dotCover, dotTrace, dotMemory, and dotPeek). This allowed us to create the ReSharper Ultimate bundle which includes the entire .NET product lineup.
In our recent posts about ReSharper Ultimate, we promised that thanks to the shared platform, dotTrace (as well as other .NET tools) would become more integrated with ReSharper.
Run configurations in ReSharper 9.2
Along with other important features and changes, ReSharper 9.2 introduces run configurations. You’ve probably already read about them in our recent blog post. In a nutshell, they give you an ability to pre-define run parameters for your startup project, an arbitrary executable, or even any static method. Then you can quickly run or debug a particular configuration without the need to set up parameters.
What does this mean for dotTrace 6.2?
So, how does dotTrace benefit from the ReSharper’s ‘run configurations’? As both products share the same platform, dotTrace is able to profile any run configuration you create.
Important! No ReSharper installation is required for this feature to work in dotTrace 6.2. Nevertheless, without ReSharper, the only way to create and profile run configurations is the Performance Snapshot Browser window. This seriously reduces the usability of the feature. That’s why having ReSharper installed is strongly recommended.
Profiling run configurations for projects and executables is not so exciting, though it does provide some sensible benefits. The main one is that you can create a number of configurations once and then quickly start profiling any configuration.
A much more interesting ability is profiling run configurations of specific static methods, and that’s what we’re going to talk about.
Profiling specific methods
With dotTrace 6.2, you can instantly profile any static method in your code. As simple as that! You don’t even need to create a special run configuration for this. Simply place the caret on the method, press Alt+Enter, and select Debug | Profile ([profiling_type])* in the action list.
* The default profiling type is specified in the Performance Snapshot Browser window available via ReSharper | Profile | Show Performance Snapshots.
Now, just imagine what this feature can do. You can profile any part of your code in place, right after you’ve written it! No need to build your solution, run the profiler, perform a usage scenario that runs your new code, etc.
For example, we’ve just written a feature in our application called Goo. There is a
Goo class that has the
Goo() method performing some complex calculations on an
public class Goo
public void Goo(int[,,] val)
... // do some complex work
Wouldn’t you like to find out instantly if this algorithm is effective? No problem, we simply add a static method that creates an instance of the Goo class and runs the Goo() method.
public static void RunGoo()
int[, ,] arrInts = ... // create some test array
Goo _goo = new Goo();
Almost there. Now we just use Alt+Enter on the method and select Debug | Profile ([profiling_type])….
In the Run Configuration Properties window that opens, among other run configuration parameters we’ll be asked whether we want to just run profiling of this configuration or run profiling and save the configuration (in case we’d like to use it again later):
After we click Execute, dotTrace will run our
RunGoo() method under a special JetLauncher process that will be profiled. Right after the method finishes working, dotTrace automatically collects a snapshot and opens it in a viewer: Timeline Viewer for timeline profiling, and Performance Viewer for all other profiling types.
There we go! We’ve got all the details about how much time our feature requires, including time values for the entire call subtree.
Note that if you use the Timeline profiling type, in addition to call time values you also get a lot of other data on your code to answer questions such as:
- How much memory does your code allocate?
- How much time does the File I/O, JIT, SQL queries processing (if there were any), etc. take?
- Were there any blocking garbage collections?
If after analyzing the snapshot we open the Performance Snapshot Browser window (by going to ReSharper | Profile | Show Performance Snapshots), we’ll see the collected snapshot. We can either delete it or keep for future analysis.
Easy, isn’t it? The suggested workflow looks similar to performance testing but it’s much easier: You don’t even have to add a separate test project to your solution or reference a unit testing framework. Simply create a static method right near the code that you want to check, and profile it in a couple of clicks when needed.