Performance problem of dlopen

[Joerg Budischewski <Joerg dot Budischewski at sun dot com>]

Hi,

sorry for probably being offtopic, but actuallly I wasn't able to
subscribe to (probably more appropriate) bug-libc mailing list via

http://sources.redhat.com/glibc/

(maybe someone can tell me how to subscribe there ?).

My name is Joerg Budischewski, I am working on the OpenOffice project
(see http://www.openoffice.org).

I have some questions to the performance behaviour of the dlopen
function, I am currently using libc 2.2.4 on my linux x86 system.

During investigations of the office startup I had a closer look at
loading shared libraries. Investigating this further, I realized a (at
least to me) surprising behaviour.

Using one dlopen() to load a shared library A (which is linked to
different other shared libraries [B-X]) is significantly slower than
using multiple dlopen() calls  for loading [B-X] before A.

In numbers, on my system the library takes 3300ms to load with one
dlopen, while using multiple dlopen takes 2100ms. I have actually played
a little around with LD_DEBUG=symbols and found out, that in the first
case, lookup for symbols which are located in dependent libraries are
searched also in the higher libraries, which leads to significantly more
lookups.

So my question is if this is a desired behaviour or can this be
considered as a performance bug ?

Another point which I am interested in is that since we are using gcc
3.x for building, loading shared libraries lazy is significantly slower,
one main reasons seems to be that unused symbols get relocated with gcc3
which have not got relocated with gcc2. When I use nm on both libraries,
the output (beside name mangling of course) looks similar. Does anyone
have an idea, what this is caused by ?

Thx for your comments in advance,

Joerg

PS: If someone is interested in reproducing the behaviour with an
OpenOffice installation set, just let me know, I can provide some
testprograms for it.