The purpose of creating a profiling use case is to analyze the performance of Symbian OS applications. In general, the objective is to define the behavior of an application and its environment when they are interacting. When designing a profiling use case, it helps to document the process and save log files.
Existing test cases created by application developers or test personnel can be used as a template. However, consider the following when designing and preparing a test of a profiling use case.
High Profiler sampling rates can cause trace files to grow excessively large, especially if the test lasts for a long time. Therefore, it is recommended that the duration of the test be as short as possible. The maximum duration of a profiling test is typically two to three minutes. There should also be reasonable gaps between input events so that specific events can be easily detected and distinguished from the trace log.
The following example describes in a high-level how to search for performance bottlenecks. Refer to Figure 1 to illustrate an example of determining time spent in a particular application and the related functions consuming most of the CPU time.
Figure 1. Examining a Specific Application
As shown in Figure 1, examine the thread load graph and select the time interval of interest. In this example, the selected time interval is 21.010 to 21.970 seconds.
Figure 1 indicates the three most CPU time consuming threads in the time frame 21-22 seconds:
Notice that only Null (ekern.exe[1]::Null_0) and Wserv_36 are checked and thus are shown in the graph. To add or remove threads from the graph, use the shift and control keys to check or uncheck multiple lines. Right-click to display a context menu for more options.
You can determine which binaries are executed by the threads during the 21-22 second interval by right-clicking inside the table and selecting Thread > Binary. This will change the graph displayed to the binary load graph in Figure 2.
Figure 2. Binary Load Graph
As shown in Figure 2, this application spends 21.25% of the time in the _reka2_ekern.exe binary. At the lowest level, you can find out which functions are executed by the binaries that execute during the 21-22 second interval by right-clicking inside either table and selecting Thread > Binary > Function. This will change the graph displayed to the function load graph in Figure 3.
NOTE: For each selected binary in Figure 2, the Analyser graphs all of that binary's samples, just as if you had selected that binary in the Binaries tab. The graph does not only show binary samples that are also associated with threads ekern.exe[1]::Null_0 and Wserv_36. We expect to deliver that functionality in a future release. Keep this in mind as you drill down into a specific thread, binary, or function.
Figure 3. Function Load Graph
Figure 3 shows that 9.90% of the execution time was spent in a single function called NKern::RestoreInterrupts(int), within the _reka2_ekern.exe binary. In the Function table scroll to see the In Binary column to determine the binary containing the function.
Select the Function Calls tab to view the Function Call Analysis tables, as shown in Figure 4.
Figure 4. Function Call Analysis
Individual functions can be selected to determine, within the time frame 21-22 seconds, which functions called the selected function and which functions were called by the selected function. You can sort functions by clicking the headings provided for each column.
Related references