Fully featured low overhead profiler for Java EE and Java SE platforms.
Easy-to-use performance and memory .NET profiler for Windows, Linux and macOS.
Secure and easy profiling in cloud, containers and clustered environments.
Performance monitoring and profiling of Jenkins, Bamboo, TeamCity, Gradle, Maven, Ant and JUnit.

CPU tracing

How CPU tracing works

CPU tracing works by instrumenting the application code to record every function call and return, along with other relevant information. This allows developers to see a complete history of the application's execution and identify specific code paths that are causing performance issues. With this information, developers can track down and optimize the problematic code paths.

Advantages

  • High detail level
  • Complete chronological history

Disadvantages

  • Significant performance overhead

Performance overhead

The performance impact of CPU tracing is generally higher than that of CPU sampling. It adds more overhead to the application because it collects a larger amount of data. Due to the additional overhead, CPU tracing may not be suitable for use in production environments, and it is typically used in testing or development environments.

Use CPU tracing when you need a detailed view of the application's execution flow to track down specific code paths causing performance issues. CPU tracing is best suited for use in testing or development environments, where the additional overhead can be tolerated.

CPU tracing and the associated overhead can be completely disabled with agent startup option disable_tracing or disable_all.

Options

tracing options

Measured time

Specify whether CPU or wall time will be measured for profiled methods.

Line number tracing

Record profiling data per source line. May increase overhead.

Adaptive tracing

Adaptive tracing reduces profiling overhead by skipping methods that are both frequently called and short-running. These methods tend to dominate tracing cost while contributing little useful detail, so excluding them makes profiling faster and results more representative.

A method is excluded based on statistics collected during the current session, and only when both thresholds are met:

  • average method execution time below the adaptive time threshold
  • method invocation count above the adaptive count threshold

When a method is excluded from adaptive tracing, its own time and invocation metrics are not recorded. Instead, its cost is reflected in its callers, which typically leads to more accurate caller-level timings due to reduced overhead.

Adaptive tracing requires no manual configuration and works across applications without predefined filters. It does, however, need a short warm-up period to gather enough data to make exclusion decisions.

Methods excluded by adaptive tracing are specially presented in UI:

  • the methods are indicated with the icon
  • because the actual time and invocation count for the methods is most likely bigger than the amount measured by the moment when the methods have been excluded from tracing, the time and invocation count values are prepended with the greater-or-equal sign, the average and own time values - with the approximately-equal sign:

Adaptive time threshold

Methods whose average execution time is below this threshold are excluded from adaptive tracing.

Adaptive count threshold

Methods with invocation count above this threshold are excluded from adaptive tracing.

YourKit uses cookies and other technologies to improve your browsing experience on our website, to show you personalized content, to analyze our website traffic, and to understand where our visitors are coming from.

By browsing our website, you consent to our use of cookies and other tracking technologies in accordance with the YourKit privacy policy.