Node:Slow linker,
Previous:Slow compiler,
Up:Compiler performance
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.