21. Performance Considerations

The GNAT system provides a number of options that allow a trade-off between

• performance of the generated code

• speed of compilation

• minimization of dependences and recompilation

• the degree of run-time checking.

The defaults (if no options are selected) aim at improving the speed of compilation and minimizing dependences, at the expense of performance of the generated code:

• no optimization

• no inlining of subprogram calls

• all run-time checks enabled except overflow and elaboration checks

These options are suitable for most program development purposes. This chapter describes how you can modify these choices.

21.1 Controlling Run-time Checks
21.2 Optimization Levels
21.3 Inlining of Subprograms

21.1 Controlling Run-time Checks

By default, GNAT produces all run-time checks, except arithmetic overflow checking for integer operations (that includes division by zero) and checks for access before elaboration on subprogram calls. Two gnat switches, -gnatp and -gnato allow this default to be modified. See section 3.2.4 Run-time Checks.

Our experience is that the default is suitable for most development purposes.

We treat integer overflow specially because these are quite expensive and in our experience are not as important as other run-time checks in the development process.

Elaboration checks are off by default, and also not needed by default, since GNAT uses a static elaboration analysis approach that avoids the need for run-time checking. This manual contains a full chapter discussing the issue of elaboration checks, and if the default is not satisfactory for your use, you should read this chapter.

Note that the setting of the switches controls the default setting of the checks. They may be modified using either pragma Suppress (to remove checks) or pragma Unsuppress (to add back suppressed checks) in the program source.

21.2 Optimization Levels

The default is optimization off. This results in the fastest compile times, but GNAT makes absolutely no attempt to optimize, and the generated programs are considerably larger and slower than when optimization is enabled. You can use the -On switch, where n is an integer from 0 to 3, on the gnatgcc command line to control the optimization level:

-O0

no optimization (the default)

-O1

medium level optimization

-O2

full optimization

-O3

full optimization, and also attempt automatic inlining of small subprograms within a unit (see section 21.3 Inlining of Subprograms).

Higher optimization levels perform more global transformations on the program and apply more expensive analysis algorithms in order to generate faster and more compact code. The price in compilation time, and the resulting improvement in execution time, both depend on the particular application and the hardware environment. You should experiment to find the best level for your application.

Note: Unlike some other compilation systems, gnatgcc has been tested extensively at all optimization levels. There are some bugs which appear only with optimization turned on, but there have also been bugs which show up only in unoptimized code. Selecting a lower level of optimization does not improve the reliability of the code generator, which in practice is highly reliable at all optimization levels.

21.3 Inlining of Subprograms

A call to a subprogram in the current unit is inlined if all the following conditions are met:

• The optimization level is at least -O1.

• The called subprogram is suitable for inlining: It must be small enough and not contain nested subprograms or anything else that gnatgcc cannot support in inlined subprograms.

• The call occurs after the definition of the body of the subprogram.

• Either pragma Inline applies to the subprogram or it is small and automatic inlining (optimization level -O3) is specified.

Calls to subprograms in with'ed units are normally not inlined. To achieve this level of inlining, the following conditions must all be true:

• The optimization level is at least -O1.

• The called subprogram is suitable for inlining: It must be small enough and not contain nested subprograms or anything else gnatgcc cannot support in inlined subprograms.

• The call appears in a body (not in a package spec).

• There is a pragma Inline for the subprogram.

• The -gnatn switch is used in the gnatgcc command line

Note that specifying the -gnatn switch causes additional compilation dependencies. Consider the following:

package R is procedure Q; pragma Inline (Q); end R; package body R is ... end R; with R; procedure Main is begin ... R.Q; end Main;

With the default behavior (no -gnatn switch specified), the compilation of the Main procedure depends only on its own source, `main.adb', and the spec of the package in file `r.ads'. This means that editing the body of R does not require recompiling Main.

On the other hand, the call R.Q is not inlined under these circumstances. If the -gnatn switch is present when Main is compiled, the call will be inlined if the body of Q is small enough, but now Main depends on the body of R in `r.adb' as well as on the spec. This means that if this body is edited, the main program must be recompiled. Note that this extra dependency occurs whether or not the call is in fact inlined by gnatgcc.

Note: The -fno-inline switch can be used to prevent all inlining. This switch overrides all other conditions and ensures that no inlining occurs. The extra dependences resulting from -gnatn will still be active, even if this switch is used to suppress the resulting inlining actions.