Adjusting CPU Profiling Options

  On this tab of the profiling settings dialog, you can adjust all options related to CPU profiling. These settings influence the detail level of CPU profiling data and the profiling overhead. They only apply to the views in the CPU view section.
  The following options are available:
  • Auto-tuning settings
    Here, you can disable auto-tuning. Furthermore you can configure the criteria for determining an overhead hot spot. A method is considered an overhead hot spot if both of the following conditions are met:
    • the total time of all its invocations exceeds a threshold in per mille of the entire total time in the thread
    • its average time is lower than an absolute threshold in microseconds
  • Time settings
    Select whether you want times shown in the CPU view section to be measured in
    • elapsed time
      With elapsed time selected, the clock time difference between method entry and method exit will be shown. Note that if the thread state selector is set to its standard setting (Runnable). Waiting, blocking and Net IO thread states are not included in the displayed times.
    • estimated CPU time
      With estimated CPU time selected, the CPU time used between method entry and method exit will be shown. On Windows and Mac OS the system supplies CPU times with a 10 ms resolution which are used to calculate the estimated CPU times. On Linux and Solaris the VM does not supply a CPU time and the estimated CPU times are roughly estimated by looking at the number of runnable threads.
  • Settings for exceptional method run recording
    Exceptional method run recording has the following configurable parameters:
    • Maximum number of separately recorded method runs
      The maximum number of the slowest invocations that are shown separately in the call tree view. Increasing this value can increase memory overhead and visual clutter in the call tree.
    • Time type for determining exceptional method runs
      The time measurement that is used for finding the slowest method invocations. Note that this setting is not linked to the thread state selector in the CPU views.
  • Call tree splitting settings

    Call tree splitting like URL splitting or method splitting have the potential to create very broad call trees that could use up all available memory. To prevent excessive memory usage, call tree splitting is capped.

    After the cap has been reached for a particular splitting type, further splits are consolidated with a description of [capped nodes]. On that node, a hyperlink allows you to reset the cap counter. In that case, new call tree splits will be recorded up to the currently configured cap.