When profiling, a number of profiling options are available for each
profiling analysis type. These options can affect the type of data that
is collected, as well as the profiling views that are displayed. In
addition, some profiling options increase the amount of memory that the
workbench uses while profiling, as well as the speed of the application
under test (together these are referred to as profiling overhead).
Show Execution Statistics Option:
Execution statistics instructs the profiler to generate aggregated
profiling statistics for profiled classes. These aggregated data are
merely time and call statistics for the methods that are run, and
cannot be used to construct a complete call graph of methods.
The advantage to this is the the profiling overhead is reduced due a lower volume of data to transfer.
However, as a consequence, only a smaller number of views are available to analyze the data.
The polling frequency refers to the amount of time that the workbench waits before requesting data, from the time of the last data request.
The Execution Statistics and Method Invocation Details tabs of the Execution Statistics view are for analyzing this data.
Show Execution Flow Option:
Execution flow instructs the profiler to generate full
profiling data for profiled classes. This means that each and every
method call by the target application will produce trace data to be
transferred back to the workbench. The advantage to this is the this
allows the workbench to construct a full method call graph for the
entire application, however, this comes at a cost of increased
application overhead.
Execution flow allows full access to all the execution analysis views,
which in addition to those of execution statistics above, also includes
the Call Tree and Method Invocation tabs, as well as the Execution
Flow, UML2 Class Interactions, and UML2 Thread Interactions views.
Collect Method CPU Time Option:
In the Profiling Tool, time measurements can be shown in clock time
or CPU (processor) time. Clock time differs from CPU time because
thread context switches and process context switches introduce
uncertainty into the calculations. Clock time does not account for this
additional physical execution behavior.
Memory Analysis is used to analyze the memory contents of a Java
application in order to see its overall effect on the size of the
application, or to explore object garbage collection.
Track Object Allocation Sites:
Enables tracking of the lines in the source code that create the
objects that are seen in the memory analysis views. This is helpful in
determining where and why objects are created. However, this option
increases the overhead associated with profiling (workbench memory use
will increase, and application performance will take a hit).
Thread analysis is used to observe how threads act during application
execution. Statistics are provided on the time each thread spends
sleeping, blocked, or waiting, as well as a visualization of their
activity.
Contention Analysis: When this
option is enabled, a graph of thread contention can be enabled from the
Threads Visualizer tab of the Thread Analysis view.
Related concepts
Overview of the Profiling Tool
Profiling resources
Related tasks
Profiling an application
Identifying memory-intensive classes
(C) Copyright IBM Corporation 2011, 2012. All Rights Reserved.