In article <11**********************@k70g2000cwa.googlegroups .com>,
<ra************@yahoo.co.intop-posted:
Please do not top-post. Now I have to go and edit your reply
to put it into a form suitable for conducting a discussion.
>John wrote:
>Does the length of my C variable names have any affect, performance-wise, on
my final executable program? I mean, once compiled, etc.,
>Would it make any difference extern int i; OR extern int
this_is_also_another_i;
>is there any relation of linking with Variable name on compiled module
? (is linker search for actuall variable name to make bin and also in
case of Dynamic Linking concept is it dependent on Variable/Function
Name ) (assume that DEBUG flag of compiler is OFF and code is
compiled/link for Optimized output.)
Anything along those lines is implementation specific.
On systems that use only 'static linking', then the external
names are fully resolved by the linker and any persistance into the
executable would be only for debugging purposes. Thus on such
systems, any performance effect on the "final executable program"
would be limited to the ones previously discussed on this thread,
about possibly larger file storage for an unstripped executable.
On systems that allow run-time linking to pre-specified
shared libraries, the names to be linked against must be present
in the the file that will undergo the final link. However, even
in the case of shared libraries, after the final link done by
the OS at the time the image is loaded for execution, the symbols
can be discarded. The performance impact of final linking against
shared libraries is highly OS dependant. We would probably be on
safe ground in assuming that the fewer symbols linked against,
the faster the final link, but even that is on shaky grounds as
the cost of doing a link depends on the number of times the
symbol address must be resolved, which could vary with optimization,
whether decreased (dead code elimination) or increased (loop
unrolling.) And if the symbol tables are kept in sorted order,
only an incremental search for the next symbol is needed. Then too,
counting just the number of symbols doesn't tell us anything about
how -many- shared libraries the system is going to look through to
resolve them all, and it doesn't tell us anything about the number
of extra symbols the shared library is going to pull in for use
in its code. You'd need a *lot* of information in order to
meaningfully analyze the cost of linking against shared
libaries.
Does a longer symbol name increase the cost of linking against a
run-time library? Not necessarily. The C89 and C99 standards
impose (different) lower bounds on the number of characters of
an identifier that must be considered signficant for linking
purposes, but that implies that an implementation could use
fixed length fields to store symbol names for linking purposes.
You don't know unless you dig down into the implementation details.
Run time linking to code in other files ("dynamic linking")
is not a feature required (or mentioned) in the C standards, so
the impact on execution speed of using different lengths of
symbols is again difficult to predict. It does differ from the
pure shared library case in that the executable must either store
or compute the symbol name in order to present to the dynamic linker,
whereas with the pure shared library case after the final link the
symbols could be discarded, so in the dynamic linking case,
either the executable must be larger to store a longer string,
or else the run-time memory use would be larger (to dynamically
allocate a longer string)... but then again, the memory for the
symbol name could be allocated as a fixed length buffer as
an automatic variable so if the name were being computed it might
be a fixed amount of storage rather than a dynamic amount...
depends how you implement the name computation. The time to effect
a dynamic link is almost certainly much higher than any additional
time that might be involved if the symbol is longer... which
might be a really trivial time difference, if the implementation
does something like hash the symbol name and do the primary
symbol table lookup based on the hash value... And then too,
it could happen that for the longer symbol name, only a small
amount of code is brought in, but that for the shorter symbol name
that additional dynamic searching was necessary in order to bring
in code called by the referenced code...
Too much variability, too many possible implementations, too much
dependance on exactly what is linked.
The whole thing is about like asking whether the post office takes
longer to deliver a letter if the address is longer.
--
Programming is what happens while you're busy making other plans.
