Vivek Verma <vve...@ilm.com> writes:
> I am trying to speedup the load and startup time of a shared
> library. After reading Ulrich Drepper's paper on "How to write shared
> libraries", it seems that the easiest thing to try would be to reduce
> the number of symbols that are globally visible. After carefully
> adding __attribute__((visibility ("default"))) to only the symbols
> that should be globally visible and using the gcc option
> -fvisibility=hidden to hide all symbols by default, I managed to
> reduce the number of globally visible symbols. But now, it seems that
> even though the number of symbols needing relocation has decreased,
> the cost of searching for a symbol in the "optimized" dso has gone
> up. Here is the output from "eu-readelf -I" before and after reducing
> the number of globally visible symbols. It seems that the cost of both
> successful and unsuccessful lookup has gone up. I haven't yet done any
> profiling but I am guessing that my runtime symbol lookup cost will go
> up. Is this to be expected?
This question is not appropriate for the mailing list gcc@gcc.gnu.org,
which is for gcc development. It would be appropriate for the mailing
list gcc-h...@gcc.gnu.org. It might be better placed on the mailing
list binut...@sourceware.org (see http://sourceware.org/binutils/ )
(assuming you are using the GNU binutils) or perhaps a glibc related
mailing list (assuming you are using glibc).
The most obvious change in your data is that the number of hash
buckets dropped from 4099 to 2053. It's entirely possible that you
were close to the boundary of when the linker decides to increase the
number of hash buckets. That issue has nothing at all to do with gcc;
it is the linker which decides the size of the dynamic hash table.
Ian
