dotTrace 2018.2 Help

Profiler Options

By default, the Profiler Options section consists of the following parameters:

  • Profiling type
    Profiling type defines what profiling method will be used and how profiling data will be collected. The following table will help you to choose a profiling type better suitable for your case.

    Profiling Method

    Profiling Type

    Description

    Use Case

    Performance Profiling
    Detailed timing information about function calls. Learn more

    Sampling

    Accurate time measurement, number of calls is not measured.

    Recommended for most cases. Ideal when you look for performance issues in your app for the first time.

    Tracing*

    Accurate calls number measurement, time measurement may be inaccurate due to profiling overhead.

    When sampling data is not enough. For example, for analyzing algorithm complexity (when info about exact number of calls is more valuable than exact call time values).

    Line-by-line*

    Each line of code is measured, call time values are inaccurate due to huge profiler overhead.
    To lower the overhead, you can profile only particular methods using filters.

    For advanced use cases only. For example, when you already know what function causes issues and want to analyze each line of it.

    Timeline Profiling
    Detailed temporal data about application threads and events. Learn more

    Timeline

    Collects temporal data about thread states, application events, and other multi-threading data. Based on Event Tracing for Windows (ETW).

    Recommended for most cases. Especially, for analyzing multithreaded apps. Use it, for example, to determine the cause of UI freezes, excessive garbage collections, uneven workload distribution, insufficient I/O, and so on.

  • Start immediately
    If selected, dotTrace will start collecting profiling data right after the launch. Otherwise, dotTrace will start collecting this information only after you manually select it in the Performance Controller window.

If Advanced is selected, you are able to additionally specify the following profiler options:

  • Time measurement
    This option defines how dotTrace must calculate calls time. For more details, refer toTime Measurement Methods.
    Typically, this is a choice between whether dotTrace should calculate time when a thread is not working or should not. More specifically, there are four options:
    • Real time (performance counter)
      Recommended. dotTrace calculates the overall real time passed between method entry and exit. This time does not depend on app threads states. Time is calculated using system performance counter.

    • Real time (CPU instruction)
      dotTrace calculates the overall real time passed between method entry and exit. This time does not depend on app threads states. Time is calculated using the CPU register.

    • Thread time
      dotTrace calculates only the time when a certain thread is running. The time when the thread is waiting or sleeping is not included in calculation.

    • Thread cycle time
      dotTrace calculates only the time when a certain thread is running. The time when the thread is waiting or sleeping is not included in calculation. Time is calculated using the CPU register.

    The table next in this section will help you to choose a time measurement method better suitable for your case.
  • Enable inlining
    Clear this option if you want dotTrace to turn off JIT-inlining and get call stacks that closely resemble the structure of application's source code.

  • High accuracy
    If selected, dotTrace will take into account time spent in profiler itself by taking more time samples.

  • Merge threads with equal names
    If selected, dotTrace will group the performance information for all threads with the same name under a single thread node in Call Tree and Threads Tree views.

  • Collect native allocations
    If selected, dotTrace will collect information about all memory allocations the profiled application does in the native (unmanaged) heap. To be able to select this option, you must have Windows Performance Toolkit installed on your computer.

  • Collect debug output
    If selected, dotTrace will collect information about all messages the profiled application sends to the debug output.

  • Collect TPL events
    If selected, profiling performance may be affected but dotTrace will collect Task Parallel Library (TPL) data. If cleared, there will be no Task nodes in Call Tree and async call nodes will lack their await and continuations parts. Learn more about how dotTrace works with asynchronous code in Analyzing Async Calls.
    Clear this option in case your application does not use multitasking or you do not need this info.

  • Use profiler API
    Enables you to control profiling directly from the code of the profiled application. For example, to take a snapshot in the exact point of your code. Learn more about using the API in Controlling Profiling Process Through API.

Optimizing Line-by-Line profiling with filters

Line-by-line profiling may be effective in particular cases but it is always time-consuming. To somehow minimize the profiling overhead, you can define some rules. According to them, not all functions are profiled line by line but only those that are really interesting for further investigation.

So you can create and set a filter or filters that match only the functions you need.

To create a new filter

  1. Click Advanced to see advanced profiling options.

  2. Click the Edit Filters button.

  3. Click Add Filter in the Profiling Filters dialog.
    For more information about the dialog, see Dialogs: Profiling Filters.

  4. In the Add Filter dialog, choose the type of filter rule:
    • Profile code in - to include the specified code item into profiling and exclude all other code items.

    • Do not profile code in - to exclude the specified code item from profiling.

    • Do not profile code marked with attribute - to exclude code items with the specified attribute from profiling.

  5. If you have chosen one of the first two options, specify an assembly, a class, and/or a method to be included or excluded from profiling. Code items are filtered independently on one another. For example, if you specify a method and leave asterisks (*) for assembly and class to exclude methods with the specified name from all assemblies and all classes.

  6. If you have chosen the last option, specify the name of the attribute that will be used to exclude symbols from profiling. Optionally, specify the assembly name where this attribute is declared.

  7. Click OK to finish adding the filter.

  8. In the Profiling Filters dialog, click Save to save and apply your modifications.

At any time you can modify the pattern defined for a filter and vary what filters to apply from session to session.

Last modified: 21 December 2018