Table view are a tabular representation of the profiling data aggregated by function calls
Table view visualizes profiling data in tabular form, showing the data from a frame or a function point of view -- unlike a flame graph, which visualizes the entire stack.
The tabular appearance of this view makes it easy to pinpoint individual frames that are using more resources than others, and zero in on functions that are ripe for optimization.
- Sorting: All columns in the table are sortable and allow you to arrange them based on a specific value. For example, sorting by Total CPU will show the frames with the highest total CPU time values first.
- Filters: All default filters are functional in Table view and the filtered results are reflected in the table.
- Runtime: The programming language of the function.
- Function name: The function name, including library context.
- Number of samples: The aggregated total number of samples of all the invocations of a given function.The sample count refers to total time including ancestry.
- Total CPU: The total time the function was on-CPU or part of an ancestry that was on-CPU (based on sample count).
- Trend: Displays the presented total CPU as higher or lower than the function’s average CPU consumption over the past week. The trend is calculated based on total time including ancestry.
- Own time: The time the function was on-CPU, not including ancestry.
- Occurrences: The number of unique stacks that a given function appears in.
A Common Use Case
A user might sort the table based on total time to view their top most CPU intensive frames, and then filter out irrelevant frames such as Kernel frames and other processes. After finding a specific frame that could be optimized, it’s simple for them to trace backwards and understand where this function is invoked, then return to their code and refactor the method to be more efficient.