Get Started
Let's go through the simplest performance profiling workflow. For example, you have an application which does or does not have performance issues. All you want is to evaluate its performance, that is find out what functions take the most time.
For the details on how to get started with timeline profiling, refer to Get Started with Timeline Profiling.
For the details on how to use the dotTrace command-line tool, refer to Use dotTrace Command-Line Profiler.
Step 1. Running dotTrace
There are several ways to start profiling your application: you can launch dotTrace as a standalone tool, from Visual Studio, or as a command-line tool (not a subject of this tutorial).
Running standalone dotTrace
This mode is ideal for applications where the original project or source code is not available or when you want to run dotTrace without having Visual Studio installed or launched. We strongly recommend that you use JetBrains Toolbox to install and launch dotTrace. To run standalone dotTrace:
Open JetBrains Toolbox.
Run dotTrace.
Running dotTrace from Visual Studio
Run Visual Studio.
Open the solution you want to profile.
From the menu bar, choose .
Step 2. Configuring and running profiling session
The next step is to configure the profiling properties and run a profiling session.
Make sure Profiling is selected in the left panel.
Now, you must add a run configuration – the configuration that tells dotTrace how to run the profiled application (the path to the application executable, command-line arguments, and other settings). Under Choose what you want to profile, New Process Run, click
Add run configuration.
In the New Run Configuration wizard, first choose Standalone application and click Next.
Specify a Path to the application executable and executable arguments if required. Click Save.
Make sure the created run configuration is selected.
Under Choose how you want to profile it, specify profiling options:
Specify the Profiling Type. This is by far the most important profiling option. There are four types available:
Sampling - the fastest method. It accurately measures calls time but doesn't get data on number of calls. This profiling type lets you quickly get the basic understanding of the application's performance.
Tracing - slower than Sampling (and due to this it cannot measure calls time precisely) but accurately measures how many times a particular function was called. Use this profiling type only when number of calls does matter, for example, for evaluating algorithm complexity.
Line-by-line - the slowest profiling type that instruments each line of code. The line-by-line profiling makes sense only when you already know what function causes issues and want to analyze each line of it. Very rarely used.
Timeline - the timeline profiling type. Think of it as of sampling data but shown on the timeline. You know not only how long a particular function was executed but also a point in time when the execution started and when it ended. This profiling type is explained in a separate tutorial about it.
Normally, if all you need is to evaluate the overall performance of the application, you should prefer the Sampling profiling type.
Under Run profiling, click Run to start profiling. dotTrace will attach to your application's process and start collecting performance data.
Step 3. Getting snapshots
Once you run the profiling session, dotTrace will run not only the profiled application, but also the 'profiling controller'. It is a separate window used to control the profiling session – collect performance snapshots, detach the profiler from the application, and so on. Thus, your next step is collecting profiling data (or, in other words, taking performance snapshot(s)) using the controller window.
Work with your application: run the functionality which performance you want to check, go through a particular usage scenario, and so on.
Once you are sure that the collected profiling data is enough, click Get Snapshot and Wait in the controller window.
Close the profiled application. This will close the controller window as well.
Step 4. Analyzing snapshot data
After you close the profiled application, dotTrace will run a separate application - dotTrace Viewer. It lets you analyze the collected performance data using several tool windows.
Filters
Filters let you scope your analysis to particular subsystems or threads.
Subsystems show you how the application execution time is distributed among various components: user and system code, WPF, strings, and so on. Learn more about subsystems.
Threads show you thread activity.
Clicking a particular subsystem or thread will work as a filter for all other tool windows. For example, if you select User code, Threads will show you only the threads that run user code, Call Tree will contain only user methods, and so on.
Filters can be chained together. For example, if you choose User code and Main Thread, Call Tree will contain only user methods running on the main thread.
Hot Spots
Hot Spots is a perfect place to start with. This view shows you the list of functions with the highest execution time. Use this view to find the slowest functions in just a glance.
Call Tree
Call Tree shows you function execution paths. Use it to quickly get down to actual application activity:
Plain List
Shows a plain list of functions. Lets you thoroughly analyze a particular function.
Source View (Windows only)
Note that whenever you select a function, Performance Viewer shows you the actual code for this function based on information provided by your application's debugging symbols. If no source code is available, Performance Viewer will try to decompile the function from the assembly.
