Other influences on code size

In addition to compiler options, there are a number of ways programming and analysis can influence the size of your source code.

High activity areas

Once you apply the techniques discussed earlier in this section, your strategy for further code size reduction depends on your objective. Use profiling tools to locate hot spots in your program; then follow one of the following guidelines:

Computed GOTOs and CASE constructs

A sparse computed GOTO can increase code size considerably. In a sparse computed GOTO, most statement labels point to the default. Consider the following example where label 10 is the default:

      GOTO (10,10,10,10,20,10,10,10,10,30,20,10,10,10,10,
     +10,20,10,20,10,20,30,30,10,10,10,10,10,10,20,10,10,...
     +10,20,30,10,10,10,30,10,10,10,10,10,10,10,20,10,30) IA(I)

      GOTO 10
30    CONTINUE
      ! ...
      GOTO 10
20    CONTINUE
      ! ...
10    CONTINUE

Although fewer cases are shown, the following CASE construct is a functionally equivalent to the example above. N is the value of the largest integer that the computed GOTO or CASE construct is testing.

      INTEGER IA(10000)
      SELECT CASE (IA(I))
        CASE DEFAULT
          GOTO 10
        CASE (5)
          GOTO 20
        CASE (10)
          GOTO 30
        CASE (11)
          GOTO 20
        ! ...
        CASE (N-10)
          GOTO 30
        CASE (N-2)
          GOTO 20
        CASE (N)
          GOTO 30
      END SELECT

In both examples, the compiler builds a branch table in the object file that contains one entry for each possibility from 1 to N, where N is the largest integer value tested. The data section of the program stores this branch table. If N is very large, the table can increase both the size of the object file and the effects of data-cache misses.

If you use a CASE construct with a small number of cases and wide gaps between the test values of the cases, the compiler selects a different algorithm to dispatch to the appropriate location, and the resulting code can be more compact than a functionally equivalent computed GOTO. The compiler cannot determine that a computed GOTO has a default branch point, so the compiler assumes that any value in the range will be selected. In a CASE construct, the compiler assumes that cases you do not specify in the construct are handled as default.

Linking and code size

Dynamic linking

When linking your XL compiler programs, dynamic linking often ensures more compact code than linking statically. Dynamic linking does not include library procedures in your object file. Instead, a reference at run-time causes the operating system to locate the dynamic library that contains the procedure, and reference that procedure from the library of the operating system. Only one copy of the procedure is in memory, even if several programs, or copies of a single program, are accessing the procedure simultaneously. This can reduce paging overhead. However, any libraries your program references must be present in your application's execution environment, or ship with your application.

Note that if your program references high performance libraries like BLAS or ESSL, these procedures are dynamically linked to your program by default.

Static linking

Static linking binds library procedures into your application's object file. This can increase the size of your object file. If your program references only a small portion of the procedures available in a library, static linking can eliminate the need to provide the library to your users. However, static linking ties your application to one version of the library which can be detrimental in situations where your application will execute in different environments, such as different levels of the operating system.