Generally, the linker needs to scan through all shared libraries on a link line in order to determine all the unsats, even in incremental links. This process may slow down incremental links. The incremental linker does not scan shared libraries and leaves detection of shared library unsats to the dynamic loader.
It is not recommended that you use the incremental linker to create final production modules. Because it reserves additional padding space, modules created by the incremental linker are considerably larger than those created in regular links.
NOTE: Any program that modifies an executable (for example, strip strip(1)), may affect the ability of ld to perform an incremental link. When this happens, the incremental linker issues a message and performs an initial incremental link.
Reusing Compiled Object Files
You can improve compile time performance by using a feature that reuses compiled object files resulting from intermediate object code
The +Oreusedir=dir option specifies a directory where the linker can save object files created from intermediate object files when using +O4 or profile- based optimization. When you compile with +I, +P or +O4, the compiler generates intermediate code in the object file. Otherwise, the compiler generates regular object code in the object file. When you link, the linker first compiles the intermediate object code to regular object code, then links the object code. With this option you can reduce link time on subsequent links by avoiding recompiling intermediate object files that have already been compiled to regular object code and have not changed.
The dir argument specifies a directory for the reuse repository, where the linker can save object files created from intermediate object files. The dir argument can be an absolute path name or relative to the directory in which the linker was invoked. If pathname does not exist, the reuse mechanism creates a directory with that pathname. If dir exists and is readable, the mechanism reuses the object files deposited there. If dir exists and is writable, the mechanism stores the object files for reuse there whenever an
The reuse repository can reside on a short file name filesystem, where file names are truncated to 14 characters. You can move or copy the reuse repository to another location, including to another filesystem, and reuse the object file from the new location by compiling with the new dir argument of +Oreusedir. Moving the repository from a long file name filesystem to a short file name filesystem forces recompilation of any object file whose full names are longer than 14 characters. Moving the repository from a short file name filesystem to a long file name filesystem forces a similar recompilation of any object file whose full names are longer than 14 characters.
When you do change a source file or command line options and recompile, a new intermediate object file is created and compiled to regular object code in the specified directory. The reuse mechanism does not remove the previous object file in the directory. You should periodically remove this directory since old object files cannot be reused and are not automatically removed. You can also delete an object file in the reuse repository to force it to be recompiled from an I- SOM.
The reuse mechanism does not rebuild an object file when the flow.data file changes. You must delete those object files stored in the reuse depository if the profile changes significantly enough to degrade the runtime performance of your code.
Improving Performance with the Global Symbol Table
The global symbol table mechanism is designed as a performance enhancement option. Enabling this mechanism causes the creation of a global symbol table which speeds up symbol lookup, by eliminating the need to scan all loaded libraries in order to find a symbol. This is particularly effective for applications with large numbers of shared libraries. This mechanism is off by default.
220 Improving Your Application Performance