The execution speed of generated code varies depending on the options specified at the command line. The table below, and the following sections, shows the options that produce the fastest running code on Alpha systems. Note that these are suggested options. A particular program may need to consider other factors, such as code size, that make different choices more suitable. You should consider the effects of each option, as well as its requirements, before deciding how to build applications for the best performance on Alpha systems.
| Option | Description |
| /Oi | Enable intrinsic functions; enabled automatically for /Ox and /O2, but not for /O1. |
| /O2 | Perform all speed optimizations. This option usually produces faster code than /Ox, but sometimes results in much larger code size. Compare the size and speed of an application compiled with /O2 to its size and speed when compiled with /Ox before deciding which options to use. |
| /J | Change default char type to unsigned. This option can produce faster code in applications that frequently manipulate values of type char. Note, however, that some applications may depend on a default setting that treats char as signed in order to operate correctly. |
| /Op– | Override floating-point precision in favor of faster code. Using this option may produce slightly different results than would be produced by following the ANSI C rules for expression evaluation. This is the default except when /Za is used. |
| /QAgq | Use quadword granularity. This option produces faster and smaller code when used with single-threaded applications. For more information, see the section /QAgq Option in Chapter 5. |
| /Ob[0 1 2 3 4] | Procedure inlining optimization. /Ob0 disables procedure inlining optimization. /Ob1 only inlines small procedures marked with _ _inline. /Ob2 enables automatic inlining, where the compiler balances code size and speed. /Ob3 favors speed over code size. /Ob4, also called benchmark inlining, tries to inline all calls, resulting in fastest possible performance but larger code size.
Depending on the size and complexity of your application, compilation times can become quite long when using /Ob4. |
| /QAieee0 | Do not support IEEE floating-point NaNs, infinites, and denormals in the compiled code. This is the default. For more information, see the section /QAieee0 Option in Chapter 5. |
| /GF | Pool strings and place them in read-only storage. Allows the compiler to schedule loads of the string literals earlier.
This can help in string-bashing codes, and reveals many coding errors with access violations. |