Benchmarking hints

Select size or speed

Optimization level and type can be specified for the entire application and for individual files. In source code, the #pragma optimize directive allows you to do this even for individual functions.

The purpose of optimization is to reduce the code size and to improve the execution speed. When only one of these two goals can be satisfied, the compiler prioritizes according to the settings you specify.

Exploring the effects of the different transformations may lead to a better result. As an example, the fact that Function inlining is more aggressive for speed optimization makes some programs smaller on the speed setting than on the size setting.

Choose a small memory model

Choose the smallest possible memory model available for your target.

Benefits:

• Smaller addresses
• Smaller instructions
• Smaller pointers
• More efficient
• Less code

Adapt the runtime environment

By default, the runtime libraries are compiled at highest size optimization level. You should rebuild them if you are optimizing for speed.

Select the needed level of support for certain standard library functionality like, locale, file descriptors, and multibytes by choosing library configuration.

Select library options for scanf input and printf output formatters according to your needs. The smallest formatters are not selected by default.

Use the right data types

Data types have big influence on code size/speed:

• Choose the data size best suited for your application
• Use unsigned char if possible–allows bit operations to be performed instead of arithmetic

Check for target-specific options

Check for target-specific options that gain performance, such as:

• Efficient addressing modes–efficient memory accesses
• Locking registers for constants/variables–more efficient code for operations on registers than on memory
• Even align functions entries–even aligned instructions gain speed
• Byte align objects–requires less memory for storage but might give bigger code

Use relevant benchmark code

• Embedded systems benchmarks should address the characteristics of embedded programs.
• Real applications are usually good for benchmarks but, make sure that the code can execute. The linker will remove un-referenced code and variables but not all linkers have this ability.
• Make sure that the test code is not affected by the test harness (test support functions). This example is actually benchmarking printf():

• Compare linked code. One compiler may inline code where another makes a library call.
• Know the application you use for benchmarking!