Node:Slow linker, Previous:Slow compiler, Up:Compiler performance

7.2 Slow Linking

Q: The compiler finishes in a few seconds, but then the linker grinds away for more than a minute, even on a very short program....

A: Try linking the trivial Hello, world! program; it should take no more than 7-10 seconds on a 486, 3-5 seconds on a Pentium. If you see much slower linking on your system, then the following advice might help you.

If you use a disk cache, make sure you enable its write-back (a.k.a. delayed-write) operation. Some people disable the delayed-write feature for safety reasons, to avoid losing files due to system crashes. If you are worried about this, you can usually gain performance without sacrificing safety by enabling delayed-write together with an option that causes the cache to flush the write-behind data before the system returns to the DOS prompt. For SmartDrv disk cache, this is achieved by specifying /N/F switches instead of /X.

For very large (several MBytes) executables which are built from a large number of small source files, the link (as opposed to the compilation) stage might be the one which needs more RAM than you have free, and thus be the bottleneck of the time it takes to build your program. Check that the size of the executable isn't larger than the amount of your free RAM. If it is, then it might make sense to use a smaller (or even no) disk cache, and allow the linker as much physical RAM as it needs. Make sure that the linker wasn't stub-edited to make its transfer buffer too small.

The first release of GCC 2.95 ported to DJGPP had a bug in the collect2 program (used during the link stage) whereby if a root directory of any drive appeared in the PATH environment variable, collect2 would try to look for files with names like C:\/foo, which caused Windows 9X to search the network (because two slashes in a row would look like a network share name). This would create an illusion of a very slow link, when in fact collect2 simply waited for the network operation to time out.

Another reason for slow linking might be that the DJGPP.ENV file by default sets TMPDIR to a tmp/ subdirectory of the main DJGPP installation directory; if DJGPP is installed on a networked drive, this means all your temporary files go back and forth through the network (and networked disks are usually not cached on your PC). In such cases, setting TMPDIR to a directory on your local drive, or to a RAM disk, would probably make linking faster.

DJGPP can be slow if it is installed on a networked drive. Generally, this is not recommended. If you have to, you should configure your network interface for best performance. Consult your network administrator.