Selecting and coloring thread states
In a visualization view, you can filter profiling data by thread state. You can color thread states inside of stack frames to make it easy to spot how the application is behaving. You can also select which thread states are displayed.
Note
The CPU view and latency view were not supported for first release of Python applications; if you open old Python profiles from before February 2021, the profiling data represents wall clock time percentages for each frame. This is similar to the latency view, without the different thread states and colors. On recent Python profiles the different views work normally.
CPU view – The default thread state view for visualizations,
it's useful to try to reduce CPU utilization. It displays frames for thread states that
correspond to CPU usage: RUNNABLE, BLOCKED, and
NATIVE. In this view, the different shades of coloring simply help with
visualization, and are based on the frame names.
Latency view – Useful to try to improve the latency of all or
part of your application. When you select it, the visualization displays frames for all of
the thread states except IDLE. All of these threads might contribute to
latency. Frames in the visualization are colored based on the thread state.
Custom view – You can choose to select the thread states for frames to include in the visualization. The threads you can select are the ones found in your profile data. You can also choose whether to color the frames based on thread states.
Example of differences between CPU view and latency view
| CPU view | Latency view |
|---|---|
|
|
The callOtherService function appears smaller in the
CPU view because it's not showing the time when the thread was in a
waiting state. In the Latency view, we still see the part where the
CPU was active (in red), but we also see when the threads were waiting (in green).
If you're trying to reduce your CPU usage, the CPU view shows you
that localActions is the most CPU heavy inside
handleServiceCall, and you might want to optimize this part.
If you're trying to improve the latency of handleServiceCall, the
Latency view shows you that most of the time is spent in
callOtherService. You can check if this is expected and try to reduce the
number of calls or speed up the execution of calls (for example, caching or batching the
requests, or calling a closer AWS Region).
