Estimating Instrumentation Overhead

Code Coverage Overhead

Overhead generated by the Code Coverage feature depends largely on the coverage types selected for analysis.

A 48-byte structure is declared at the beginning of the instrumented file.

Depending on the information mode selected, each covered branch is referenced by an array that uses

• 1 byte in Default mode

• 1 bit in Compact mode

• 4 bytes in Hit Count mode

The actual size of this array may be rounded up by the compiler, especially in Compact mode because of the 8-bit minimum integral type found in C and C++.

See Information Modes for more information.

Other Specifics:

• Loops, switch and case statements: a 1-byte local variable is declared for each instance

• Modified/multiple conditions: one n-byte local array is declared at the beginning of the enclosing routine, where n is the number of conditions belonging to a decision in the routine

I/O is either performed at the end of the execution or when the end-user decides (please refer to Coverage Snapshots in the documentation).

As a summary, Hit Count mode and modified/multiple conditions produce the greatest data and execution time overhead. In most cases you can select each coverage type independently and use Pass mode by default in order to reduce this overhead. The source code can also be partially instrumented.

Memory and Performance Profiling and Runtime Tracing

Any source file containing an instrumented routine receives a declaration for a 16 byte structure.

Within each instrumented routine, a n byte structure is locally declared, where n is:

• 16 bytes

• +4 bytes for Runtime Tracing

• +4 bytes for Memory Profiling

• +3*t bytes for Performance Profiling, where t is the size of the type returned by the clock-retrieving function

For example, if t is 4 bytes, each instrumented routine is increased of:

• 20 bytes for Memory Profiling only

• 20 bytes for Runtime Tracing only

• 28 bytes for Performance Profiling only

• 36 bytes for all Runtime Analysis features together

Memory Profiling Overhead

This applies to Memory Profiling for C and C++. Memory Profiling for Java does not use source code insertion.

Any call to an allocation function is replaced by a call to the Memory Profiling Library. See the Target Deployment Guide for more information.

These calls aim to track allocated blocks of memory. For each memory block, 16+12*n bytes are allocated to contain a reference to it, as well as to contain link references and the call stack observed at allocation time. n depends on the Call Stack Size Setting, which is 6 by default.

If ABWL errors are to be detected, the size of each tracked, allocated block is increased by 2*s bytes where s is the Red Zone Size Setting (16 by default).

If FFM or FMWL errors are to be detected, a Free Queue is created whose size depends on the Free Queue Length and Free Queue Size Settings. Queue Length is the maximum number of tracked memory blocks in the queue. Queue Size is the maximum number of bytes, which is the sum of the sizes of all tracked blocks in the queue.

Performance Profiling Overhead

For any source file containing at least one observed routine, a 24 byte structure is declared at the beginning of the file.

The size of the global data storing the profiling results of an instrumented routine is 4+3*t bytes where t is the size of the type returned by the clock retrieving function. See the Target Deployment Guide for more information.

Runtime Tracing Overhead

Implicit default constructors, implicit copy constructors and implicit destructors are explicitly declared in any instrumented classes that permits it. Where C++ rules forbid such explicit declarations, a 4 byte class is declared as an attribute at the end of the class.

Related Topics

Reducing Instrumentation Overhead | Source code instrumentation overview