## Adjusting Method Call Recording Options |

| On this tab of the profiling settings dialog, you can adjust all options related to method call recording. These settings influence the detail level of CPU profiling data and the profiling overhead.

| The following options are available: Enable method call recording When you record CPU data or allocations, JProfiler collects information about the call tree. You might want to record allocations without the overhead of recording the allocation call stacks: If you don't need the allocation view in the heap walker, the allocation call tree and the stack trace information in the monitor usage views, you can switch off method call recording. This will speed up profiling considerably and reduce memory usage. Method call recording type Select the method call recording type for CPU profiling as one of Dynamic instrumentation When dynamic instrumentation is enabled, JProfiler modifies filtered classes on the fly as they are loaded by the JVM to include profiling hooks. Accuracy of non-timing related stack information (like allocation information) is high, invocation counts are available and J2EE payloads can be annotated in the call tree, but calls from Java core classes are not resolved. The overhead and timing accuracy varies depending on what classes are instrumented. Java core classes (`java.*`) cannot be profiled this way and are filtered automatically. Sampling When sampling is enabled, JProfiler inspects the call stacks of all threads periodically. Sampling has extremely low overhead even without any filters. Accuracy of non-timing related stack information (like allocation information) is low and invocation counts are not available. Only methods that take longer than the sampling period or methods called frequently are captured by sampling. Sampling is ideally suited for use without any method call filters. To temporarily switch off all filters, you can use the `Disable all filters for sampling` setting instead of deleting all filters in your configuration. In that way you can create a profiling settings template that ignores your filter configuration and alternate between using filters and using no filters at all. If sampling is enabled, the sampling frequency can be adjusted. The default value is 5 ms. A lower sampling frequency incurs a slightly higher CPU overhead when profiling. Note: allocations will be reported according to the call traces recorded by the sampling procedure. This may lead to incorrect allocation spots. Line numbers By default, JProfiler does not resolve line numbers in call trees. If you enable `show line numbers for sampling and dynamic instrumentation`, line numbers will be recorded and shown. If the aggregation level is set to "methods" and a method calls another method multiple times in different lines of code, line number resolution will show these invocations as separate method nodes in the call tree and the allocation call tree. Backtraces in the hotspot views will also show line numbers. Note that a line number can only be shown if the call to a method originates in an unfiltered class. 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.