TITLE: linker efficiency

(Newsgroups: comp.lang.c++.moderated, 9 Dec 99)

DEVELYN: Richard Develyn

> But just to get one thing clear, is the time to link proportional to:
>
> a) The number of objects files?
> b) The number of dependancies between object files?
> c) Both, or something else?

CLAMAGE: stephen.clamage@sun.com

Both, and other things. The linker typically needs to read all of each
object file. The bigger the file, the longer it takes to
read. The linker typically generates an executable file. The bigger the
total size of the program, the longer it takes to
write the output file. The linker must also resolve all references that were
deferred to link time. The more of them there
are, the longer it takes to complete the linking process.

DEVELYN:

> What is the effect of including object files which are not used?

CLAMAGE:

That will depend on the linker. Typically, if you tell the linker to include
an object file , the file will be copied into
executable. It would be dangerous for a linker to assume that just because
there are no references to any entry point in
the file it should be
skipped. You might link to a dynamic library that makes calls into that
module.

DEVELYN:

> What happens with libraries?

CLAMAGE:

It makes a difference whether the library is static or dynamic.

A static library is like a collection of object files, typically with an
index so that unreferenced modules are completely
skipped. (No contradiction here: when say to link a specific object file,
the linker includes it. When you say to process a library, the
linker picks out the used portions.)

A dynamic library gets processed as a collection of symbols,
not as a collection of object files. References to those symbols get
replaced by whatever the OS uses for accessing
symbols in a dynamic library. The linker does not copy the library contents.

DEVELYN:

> As a corrolary, with test driver creation, is it better to create a
smaller
> number of large test driver apps (which test many classes) or a larger
> number of small test driver apps?

CLAMAGE:

There is no one answer to that question.

If you expect all tests to pass, it will usually be more efficient to run
one comprehensive test program than many small
ones. But if the big test overloads the system (e.g., causes thrashing), you
might get worse performance.

Sometimes one failure prevents tests later in the program from
being run (the program might abort, for example). In that case, you have to
fix the first problem before getting any other
test results. Ordinarily, you would prefer to find out about all failures in
one test run.

Some test suites that we use are available in two forms. From one set of
test source code, a script generates one big
test program using all the test code, and also generates a separate complete
test program for each of the tests. The programmer can then run either
version.


KANZE: kanze@gabi-soft.de, 14 Dec 99

[snip] ...it has been my
experience that link times often depend on template use as well.  In
most modern compilers (including the current Sun native compilers),
templates are instantiated at compile time, and the effect on link time
is largely dependant on the number of additional object files generated.
Some compilers, however, may still generate instantiations into every
object file, with the linker eliminating duplicates; this results in
less object files, but in significantly more bytes being read by the
linker.  There may also be some compilers still floating around doing
CFront style template instantiation, in which templates were
instantiated at link time -- this can result in the "linker" compiling a
significant part of the application, with link times increasing
horrendously.



_______________________________________________
cpptips mailing list
http://cpptips.hyperformix.com