Compile With Appropriate Options and Multiple Source Files

During the earlier stages of program development (such as for the debug configuration in the visual development environment), you can use compilation with minimal optimization. For example:

  DF /compile_only /optimize:1  sub2.f90
  DF /compile_only /optimize:1  sub3.f90
  DF /exe:main.exe /debug /optimize:0  main.f90 sub2.obj sub3.obj

During the later stages of program development (such as for the release configuration), you should:

Avoid using incremental linking.
Specify multiple source files together and use an optimization level of at least /optimize:4 on the DF command line to allow more interprocedural optimizations to occur. For instance, the following command compiles all three source files together using the default level of optimization (/optimize:4):
```
  DF /exe:main.exe main.f90  sub2.f90  sub3.f90
```
When using the visual development environment, consider reducing the number of top-level source files by copying your application to a separate project. The separate project should use only one (or a few) top-level Fortran source files that contain INCLUDE statements for the other source files. Or, you can build your application from the command line, which allows many source files to be compiled together with a single command. For information on creating (exporting) makefile for command-line use, see Files in a Project; for information about using NMAKE, see Building Projects with NMAKE.

Compiling multiple source files together lets the compiler examine more code for possible optimizations, which results in:

Inlining more procedures
More complete data flow analysis
Reducing the number of external references to be resolved during linking

When compiling all source files together is not feasible (such as for very large programs), consider compiling related source files together using multiple DF commands rather than compiling source files individually.

If you use the /compile_only option to prevent linking, also use the /object:file option so that multiple sources files are compiled into a single object file, allowing more optimizations to occur.

Visual Fortran performs certain optimizations unless you specify the appropriate DF command-line options or corresponding visual development environment options in the Optimization category of the Fortran tab (see Categories of Compiler Options). Additional optimizations can be enabled or disabled using DF command options or in the visual development environment Project Settings dialog box Fortran tab.

The following table shows DF options that can directly improve run-time performance on both ia32 and ia64 systems. Most of these options do not affect the accuracy of the results, while others improve run-time performance but can change some numeric results.

Options Related to Run-Time Performance

Option Names	Description	For More Information
/align: keyword	Controls whether padding bytes are added between data items within common blocks, derived-type data, and Compaq Fortran record structures to make the data items naturally aligned.	See Data Alignment Considerations.
/architecture: keyword	Requests code generation for a specific chip generation. On ia32 systems, certain ia32 chip generations use new instructions that provide improved performance for certain applications, but those instructions are not supported by older ia32 chips.	See /architecture
/fast	Sets the following performance-related options: /alignment:(dcommons, records, sequence), /architecture:host /assume:noaccuracy_sensitive /math_library:fast (which changes the default of /check:[no]power), and /tune:host	See description of each option
/assume:noaccuracy_sensitive	Allows the compiler to reorder code based on algebraic identities to improve performance, enabling certain optimizations. The numeric results can be slightly different from the default (accuracy_sensitive) because of the way intermediate results are rounded. This slight difference in numeric results is acceptable to most programs.	See Arithmetic Reordering Optimizations
/assume:buffered_io	Allows records that are otherwise written (flushed) to disk as each record is written (default) to be accumulated in the buffer and written as a unit. Using buffered writes usually makes disk I/O more efficient by writing larger blocks of data to the disk less often.	See Efficient Use of Record Buffers and Disk I/O
/inline:all	Inlines every call that can possibly be inlined while generating correct code. Certain recursive routines are not inlined to prevent infinite loops.	See Controlling the Inlining of Procedures
/inline:speed	Inlines procedures that will improve run-time performance with a likely significant increase in program size.	See Controlling the Inlining of Procedures
/inline:size	Inlines procedures that will improve run-time performance without a significant increase in program size. This type of inlining occurs with optimization level /optimize:4 or /optimize:5.	See Controlling the Inlining of Procedures
/math_library:fast	On ia32 systems, requests that arguments to the math library routines are not checked to improve performance.	See /math_library
/optimize:level	Controls the optimization level and thus the types of optimizations performed. The default optimization level is /optimize:4 (except in the visual development environment for a debug configuration), unless you specify /debug, which changes the default to /optimize:0 (no optimizations). Use /optimize:5 to activate loop transformation optimizations and (on ia64 systems) the software pipelining optimizations.	See Optimization Levels: the /optimize Option
/pipeline (ia64 only)	Activates the software pipelining optimization (a subset of /optimize:5) on ia64 systems.	See /[no]pipeline (ia64 only)
/transform_loops	Activates a group of loop transformation optimizations (a subset of /optimize:5).	See /[no]transform_loops
/tune:keyword	Specifies the target processor generation (chip) architecture on which the program will be run, allowing the optimizer to make decisions about instruction tuning optimizations needed to create the most efficient code. Keywords allow specifying one particular processor generation type, multiple processor generation types, or the processor generation type currently in use during compilation. Regardless of the setting of /tune keyword, the generated code compiled on ia32 systems will run correctly on all implementations of the ia32 architecture.	See Requesting Optimized Code for a Specific Processor Generation
/unroll:num	Specifies the number of times a loop is unrolled (num) when specified with optimization level /optimize:3 or higher. If you omit /unroll: num, the optimizer determines how many times loops are unrolled. Primarily on ia32 systems, increasing the default unroll limit may improve run-time performance for certain applications.	See Loop Unrolling

The following table lists options that can slow program performance on ia32 and ia64 systems. Some applications that require floating-point exception handling might need to use a different /fpe:n option. Other applications might need to use the /assume:dummy_aliases or /vms options for compatibility reasons. Other options listed in the table are primarily for troubleshooting or debugging purposes.

Options that Slow Run-Time Performance

Option Names	Description	For More Information
/assume:dummy_aliases	Forces the compiler to assume that dummy (formal) arguments to procedures share memory locations with other dummy arguments or with variables shared through use association, host association, or common block use. These program semantics slow performance, so you should specify /assume: dummy_aliases only for the called subprograms that depend on such aliases. The use of dummy aliases violates the FORTRAN 77 and Fortran 90 standards but occurs in some older programs.	See Dummy Aliasing Assumption
/compile_only	If you use /compile_only when compiling multiple source files, also specify /object:file to compile many source files together into one object file. Separate compilations prevent certain interprocedural optimizations, the same as using multiple DF commands or using /compile_only without the /object:file option.	See Compile With Appropriate Options and Multiple Source Files
/check:bounds	Generates extra code for array bounds checking at run time.	See /check
/check:overflow	Generates extra code to check integer calculations for arithmetic overflow at run time. Once the program is debugged, you may want to omit this option to reduce executable program size and slightly improve run-time performance.	See /check
/fpe:n values	On ia32 systems, /fpe:3 provides the best performance. Using /fpe:0 slows program execution. On ia64 systems, using /fpe:0 provides the best performance. Using /fpe:3 slows program execution.	See /fpe
/debug:full, /debug, or equivalent	Generates extra symbol table information in the object file. Specifying /debug also reduces the default level of optimization to /optimize:0.	See /debug
/inline: none /inline: manual	Prevents the inlining of all procedures (except statement functions).	See Controlling the Inlining of Procedures
/optimize:0, /optimize:1, /optimize:2, or /optimize:3	Reduces the optimization level (and types of optimizations). Use during the early stages of program development or when you will use the debugger.	See /[no]optimize and Optimization Levels: the /optimize Option
/vms	Controls certain VMS-related run-time defaults, including alignment. If you specify the /vms option, you may need to also specify the /align:records option to obtain optimal run-time performance.	See /[no]vms

For more information:

On compiling multiple files, see Compiling and Linking for Optimization.