Take a look at
DoActionC, for instance, in the C# implementation of our sample application. This routine takes near 0.6%0.6%0.6% of the total time without children and about 13.6%13.6%14.3% of the total time with its child calls included. (To view the percents within the % Time and % with Children columns, right-click the column header and select the proper display style from the context menu). It means that most of the time outlay is for child routines that are called from the
DoActionC routine. Therefore, we need to spend some time reviewing the routines called from
To look at the source code for
DoActionC in the Report panel and switch to the Editor panel click
DoAction in the Report panel, select Show Source File from the Edit menu and switch to Visual Studio’s Code Editor double-click
DoActionC in the Report panel and switch to Embarcadero RAD Studio’s Editor panel:
We can now review the problem source code. As expected,
DoActionC does not perform any complex calculations. It simply calls two other routines:
DoActionB. Let’s switch to the Calls page of the Details panel and look at the profiling results:
Now we know that the
DoActionC routine has only been called from one point in the program (from the
ProfilingTest parent routine).
DoActionC has called two child routines -
DoActionB, which are listed in the Children pane.
We also know that
DoActionB has been called 101 times and it takes about 6.3 seconds (or 7.5% of the total execution time)6.3 seconds (or 7.5% of the total execution time)5.1 seconds (or 7.1% of the total execution time).
DoActionA has been called 11 times and it takes about 5.5 seconds (or 6.6% of the total execution time)5.5 seconds (or 6.6% of the total execution time)5.5 seconds (or 7.7% of the total execution time).
To improve performance, a possible solution would be to decrease the number of calls to
DoActionB or to increase the speed of
One more important characteristic of the application performance is the critical path. This is the longest route of routine calls in the entire application. To measure the "length", you can use values of any numeric column displayed in the Report panel. For instance, it can be useful to get the critical path calculated for the Time with Children column (total time spent on each routine’s execution including all its routine calls). To do this, click the
Form1::Main routine in Report and switch to the Call Tree panel, whose Children pane displays the entire tree of routines called from
Main. We have chosen this routine because it has no parents among the routines we profiled (in other implementations of our sample, there can be a different root routine). This gives us the complete call tree.
Select Customize from the context menu. This will call the Call Tree Options dialog. In the dialog, select the Show critical path for column check box and choose Time with Children in the dropdown list of columns. Press OK to close the dialog. Now we can see the critical path: this is the route displayed in bold.
Routines that belong to the critical path need optimizing since they seriously affect the overall performance of the application. As you can see, the critical path includes
DoActionB, which we already detected as the routines that require optimization.
The Report and Details panels and the Editor’s gridthe Code Editor’s grid support custom summary fields, which can help you, say, to view the total time spent on executing all of the routines listed in Report. Also, if there are more than one record selected in any of these panels, the summary fields display information that corresponds to the selected records, rather than to all records.