Home > Profiling Tasks > Custom Profiling > CPU Profiling
Profiling Single-Threaded and Multi-Threaded Applications
Profiler profiles methods that it has instrumented irrespective of the thread
that executes these methods. That is, every thread that enters the root method
starts to generate profiling data, and continues until it leaves the root method.
However, it often appears unnecessary to profile each thread that ever entered
the root method, if it is already known that all threads are going to behave
in the same way. In order to reduce overhead in this situation, you can set
a limit on the maximum number of concurrent threads to profile. By default this
number is 32, which we consider enough for most of multi-threaded applications.
Setting this to value n will cause Profiler to profile only the first n threads
that entered the root method, which, if n is small, may lead to substantial
reduction of the overhead.
On the other hand, with multi-threaded applications it is often important to
see all the threads that your application launches when you just begin to analyze
it. To address this issue, we have added an option which makes it
treat all void run() methods of all classes that extend java.lang.Thread
or implement java.lang.Runnable, and are loaded by the VM after your
designated root method has been started, as implicit roots. That is, the void
run() method of such classes is instrumented once the class is loaded.
This process, however, does not start until the root method is loaded, and works
only for classes loaded after the root class is loaded. If your root method
is the main method of the application, all application threads are instrumented;
otherwise only the threads started after the root method invocation are instrumented.
To turn this feature on, check Instrument -> Threads started after root
method.
See also
