dotTrace 2016.2 Help

Get Started with Performance Profiling

dotTrace provides two methods for profiling your apps: performance and timeline. To some extent, both methods are interchangeable. Nevertheless, there are types of tasks where one or another profiling method is more suitable. For example, the performance profiling method described in this section is better suited for more straightforward "What is the slowest method" tasks, or for the tasks when you need to take an in-depth look at the algorithm complexity. The timeline profiling method, in its turn, collects not only stack trace data but also the data about calls distribution in time. This method shows its best on issues where the order of events does matter: UI freezes, sync delays, excessive garbage collections, and so on. For details on how to use timeline profiling, refer to the next tutorial.

Now, let's take a look at the simplest performance profiling workflow. For example, we have some application which does or does not have performance issues. So, all we want is to evaluate the performance, i.e. find out what methods take the most time.

Step 1. Running dotTrace

There are two ways to start profiling your application: you can either launch dotTrace as a standalone tool or from Visual Studio.

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. To run standalone dotTrace:

  1. Start dotTrace from the Windows Start menu.
    Running_dotTrace_1
    This will run the dotTrace Home window.

Running dotTrace from Visual Studio

  1. Run Visual Studio.
  2. Open the solution you want to profile.
  3. In the menu, choose ReSharper | Profile | Profile Startup Configuration Performance Profiling....
    resharper_menu_upd

Step 2. Configuring and Running Profiling Session

  1. In the left panel in New Session, select Local. This indicates, we want to profile the application located on this computer.
    t3_local_session
  2. In the central panel in Profile Application, select Standalone. Note that dotTrace is able to profile different kinds of applications including web apps hosted on IIS server, WCF services, and many others*.
    t3_app_type
  3. In the right panel, specify profiling options.
    t3_profiler_options
    • In Application, specify path to the application executable.
    • In Profiling type, specify the profiling type.

      This is by far the most important profiling option. You can choose among:

      • Sampling - the fastest method. It accurately measures calls time, but doesn't get data on number of calls. This profiling type allows you to quickly get a general idea 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 method was called. Use this method when Sampling data is not enough, e.g. for evaluation of algorithms complexity.
      • Line-by-line - the slowest method that measures 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.
      • Timeline - used to perform timeline profiling. Read about it in a separate tutorial.
      As you can see, if we need just to evaluate the overall performance of the application, we should prefer the Sampling method.
  4. 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 so-called 'profiling controller' - a separate window used to control the profiling session - collect performance snapshots, detach from the profiled applications, and so on. Thus, the next step is to collect profiling data (or, in other words, take performance snapshot(s)) using the controller window.

t1_profiling_controller

  1. Work with your application: run the functionality whose performance you want to check, perform a particular usage scenario, etc.
  2. Once you are sure that the collected profiling data is enough, click Get Snapshot and Wait in the controller window.
  3. 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 - Performance Viewer. It allows you to analyze the collected performance data using a handy UI.

The UI consists of a number of views that allow you to look at the data from different angles:

Hot Spots

You may want to start with Hot Spots. This view simply shows you the list of functions with the highest execution time. Use this view to find the slowest methods in just a glance.

t3_hot_spots

If you want to perform a more thorough analysis, you can use other Performance Profiler views: Threads Tree, Call Tree, and Plain List.

Threads Tree

Allows you to view and analyze threads activity in your application.

t3_threads

Call Tree

Call Tree shows you all method calls in all threads. Each top-level node represents a top-level function which was executed by a certain thread. Use this view to quickly get down to actual application activity:

t3_call_tree

Plain List

Shows a plain list of methods. Allows you to thoroughly ananlyze a particular method.

t3_plain_list

Source View

Note that whenever you select a method, Performance Viewer shows you the actual code for this method based on information provided by your application's debugging symbols. If no source code is available, Performance Viewer will try to decompile the method from the assembly.

t3_source_view

Learn More

Once you've mastered these basics, learn the various techniques in analyzing profiler data. Performance Viewer includes great features like remote profiling, navigating through method calls, filtering and folding and estimating performance gains. Read about these and other features in particular sections of this guide.

Last modified: 15 December 2016