Profiling
Related article: Tutorial - Using Profiling Information to Improve Locate Options
When writing the embedded source code to run on a target processor within a design, the 'holy grail' is to implement the required algorithms as efficiently and as optimizable as possible. An elegant algorithm may turn out to be time-inefficient, leading to overall performance degradation. Multiple slow-executing algorithms will only serve to compound the problem. As a further aid in debugging your embedded code, Altium Designer provides Profiling technology.
Profiling is the process of collecting statistical data about a running program and can be used to determine functions of the embedded code are called, how often they are called, and how long they take to execute. The Profiling technology provides a number of profiling tools that together enable you to fine tune the performance of your code. Performance problems can be solved by:
- Identifying time-consuming algorithms and rewriting the code using more time-efficient algorithms.
- Identifying time-consuming functions and selecting the appropriate Compiler optimizations for these functions (e.g. enable loop unrolling or function inlining).
- Identifying time-consuming loops and adding the appropriate pragmas to enable the Compiler to further optimize these loops.
Adding Profiling Functionality to an Embedded Project
The C Compiler in the toolchain of each 32-bit target processor platform contains an option to add code to your embedded software project, which handles the profiling process for you. This method of profiling is often referred to as code instrumentation. From within Altium Designer, this option – Generate profiling information – is enabled as part of the project options for the embedded software project (Figure 1). Further sub-options are provided, which allow you to specify what kind of information is profiled.
Figure 1. Accessing debug features from the processor's instrument panel.
With profiling enabled, code is added to the original program – code that is needed to gather the required profiling data. The code size of your program will therefore be increased. Profiling data is captured in real-time, as the program executes. This will result in longer execution time for the program. In addition, dynamically allocated target memory is used to initially store the data. The heap of your program must therefore be large enough to store this captured data. The more detailed the profiling information you specify, the larger the overhead in terms of execution time, code size and heap space required.
Viewing Profiling Results
When the debug session is stopped, the profiling data is written from target memory to an intermediate file and then ultimately translated into an XML file (ProfilerResult_DateTime.xml). The data is then loaded, and displayed, in the Profiler view (Figure 2), accessible from the Debug toolbar.
Figure 2. Peruse profiling results in the Profiler view.
Three tabs are provided (All Functions, Files, Functions) allowing you to quickly view profiling data for all functions across all C source files, or only those functions resident in specified source file(s). The main Results region of a tab is where the timing information can be found. By selecting a particular function in this region, you can also gain further information related to that function, such as which functions call it, or are called by it.
Use the associated Profiling Target panel (Figure 3) to reduce what can be an overwhelming amount of profiling information. Initially all functions in all C source files for the embedded software project are enabled for display in the Profiler view. Disable the entries for those you wish to remove as required.
Figure 3. Profiling Target panel.
The lower region of the Profiling Target panel lists all previous profiling results. Double-clicking on an entry will load the results in the associated file, displaying them in the Profiler view. In this way, you can switch between sets of results that may have been captured using different profiling options.