Re: On the cost of libraries

[Ulrich Drepper <drepper redhat com>]

I reply to Owen's mail but it's not specific to his.

This whole thread is somewhat an excuse.  Some here try to find a
scapegoat for the slow startup and look for reasons external to GNOME.
Let's see, ld.so perhaps?

Just a few points which you hopefully take serious since I'm dealing
with ld.so every day and have been over all this optimization stuff
many many times.


Having many DSOs isn't too bad *if* your code is designed to handle it
appropriately.  Simply linking in all of the DSOs is not a good solution.

People suggesting to implement and use lazy loading miss several
points.  Yes, I looked at implementing it and might do it some day,
but it's not going to help much.  The problems are that you have to
explicitly mark a DSO to be lazily loaded.  This has to happen when
building the application/DSO linked with it.  Like several already
existing extensions this would be hardly used.  Second, the data the
application must contain and load at runtime will grow quite a bit.
Alone for lazy loading this is not justified.  Maybe with preloading
this will change but it's something which has to be closely evaluated.
Third, new code would have to be added to the runtime lookup code.
This additional code would hardly ever be used but is executed all the
time.  For every first use of a PLT entry ld.so would have to consult
yet another array to see whether the DSO is loaded.  Fourth, the
biggest problem, lazy loading is a consistency problem.  Since ld.so
should not even look at the DSO to be lazily loaded (otherwise the
effect would be nullified) this means it has to trust the information
recorded in the application.  If this information gets stale all hell
brakes loose.  Fifth, lazy loading is not compatible with prelinking.
Not loading all prelinked DSOs would mean a conflict of size and/or
position of the loaded DSO would make the whole application come to a
stop.  And finally, sixth, as already mentioned, copy relocations are
the enemy and they are used a lot.


Instead of relying on lazy loading (which will truly disappoint you
even if it would be implemented) just use what is there.  There are
and will be soon quite a lot of helps:

- use the -O1 option for ld.  This will optimize the hash table.  ELF's
  hash function is poor but cannot be changed.  This options tries to
  make the best out of it.

- today's linker and glibc 2.2.5 support relocation combining.  Ld should
  enable this option by default on most architecture so not much is needed
  to do.  It has the effect of making relocation processing faster,
  especially relative relocations (see below).

- prelinking will officially be implemented in glibc 2.3.  It provides
  big improvements since relocations don't have to be performed.  This
  means the GOT sections don't have to be copied-on-write all the time.
  The whole relocation step can mostly be skipped.  But it requires a
  certain design of DSO as to avoid conflicts.  These conflicts are
  recognized by ld and recorded in the application and relocations have
  to happen just as before for these conflicts.  Again, good design
  of a DSO is essential.

- ordering the DSO content will get important.  We are working on tools
  to make this easier to do but again here the code design is essential.
  The reordering can happen at best on ELF section level, maybe only
  at object file level.  I.e., code which use large source files which
  define many functions will not be able to take advantage of this.  One
  might use gcc's -ffunction-sections option but this is no real substitute
  for a clean design since handling of static functions is left up to the
  tool doing the reorganization.