Subsystems

How subsystems work

With a few exceptions (see Special Subsystems below), each subsystem simply groups calls made within a certain namespace or assembly.

For example, all calls of the methods declared in the WindowsBase, PresentationCore and PresentationFramework assemblies are grouped under the WPF subsystem. The time shown next to WPF in the Subsystems filter is the total time of all these calls for all selected threads.

Subsystem name.

Total time spent in a particular subsystem summed up for all selected threads.

The percentage of time spent in a subsystem relative to the total selected time.

After you select a subsystem, other filters will show data only for the time intervals where the selected subsystem has worked.

Special subsystems

There is a number of subsystems that stand out of the row. This means that contribution of such subsystems is calculated not by grouping calls from particular assemblies and namespaces but based on other data.

• System code: all source code that does not match the rules in the chosen active profile and belongs to standard system libraries.

• User code: all source code that does not match the rules in the chosen active profile and does not belong to standard system libraries.

• GC Wait: all time intervals where threads wait for other threads to finish the blocking garbage collection. Note that the GC Wait time is calculated somewhat differently comparing to the Garbage Collection event.

• JIT: all activities related to JIT compilation. Calculated based on ETW events data.

• SQL query: all activities related to communication with SQL server. Calculated based on ETW events data.

• File I/O: all activities related to file operations. Note that this subsystem is calculated based not only on file I/O ETW events but also based on grouping calls from the System.IO and other namespaces. That's why File I/O subsystem's time may slightly differ from the time of the File Operations event.

• Waiting for CPU: indicates that a thread is ready to run on the next available CPU core. Typically, these are inevitable pauses related to switching a thread between CPU cores or changing thread state from Waiting to Running. Long Waiting for CPU intervals may mean thread starvation and CPU overload.

  Calculated based on ETW events data.

• Awaiting Time: (applicable to asynchronous code only) time intervals when async methods waited until their tasks are finished. Learn more about how to analyze asynchronous code.

• Lock Contention: takes place when a thread tries to acquire the lock to an object which is already acquired by other thread*. Until the object is released, the thread is blocked (in other words, it is in the Waiting state). In some cases, this may lead to a so-called serial execution which negatively affects application performance. The serial execution pattern can be easily determined using the Threads diagram. Instead of threads running in parallel, you will see only one thread running at a time.

  note

  * dotTrace detects lock contention only for the objects locked by the Monitor.Enter method or the lock statement.

  Calculated based on ETW events data.

Configuring subsystems

Subsystems in Timeline Viewer is a counterpart of the corresponding feature in Performance Viewer. Therefore, for the information about how to configure Subsystems, refer to the corresponding sections of the Performance Viewer documentation:

• Adding a new subsystem

• Duplicating a subsystem

• Creating a new profile