Re: OO.o / ld / -Bsymbolic patch ...

[Jakub Jelinek <jakub at redhat dot com>]

On Tue, Jul 05, 2005 at 04:40:08PM +0100, michael meeks wrote:
> On Tue, 2005-07-05 at 17:27 +0200, Jakub Jelinek wrote:
> > That begs the question, are you using prelink or not?
> 
> 	Not, no - partly becuase my (older) system doesn't support it out of
> the box, but partly also because I really don't like the prelinking
> concept at all :-) it seems to me a nasty hack to overcome a bad design
> (but most likely I've misunderstood it).
> 
> > This is on a prelinked system, so I use LD_PRELOAD=libSegFault.so
> > to make prelinking useless (libSegFault.so has < 30 relocations,
> > so shouldn't change the numbers much):
> 
> 	Interesting.
> 
> > LD_PRELOAD=libSegFault.so LD_DEBUG=statistics oowriter
> >       4630:                final number of relocations: 62756
> >       4630:     final number of relocations from cache: 121745
> > LD_DEBUG=statistics oowriter
> >       4669:                final number of relocations: 43733
> >       4669:     final number of relocations from cache: 99881
> 
> 	OK - so, my binutils change does slightly better without the various
> complexities, latencies, limitations etc. of pre-linking :-)

Not sure what complexities/latencies/limitations you are talking about.
Anyway, when I cooked up a quick hack (don't really want to build OOo
myself, so all I did was:
1) find what libraries are listed in pagein-writer + pagein-common and
   not in ldd ./soffice.bin
2) added one selected library from ldd ./soffice.bin to that list
3) created a dummy shared library that does nothing but links against
   those extra 18 shared libraries
4) copied soffice.bin to swriter.bin, prelink -u swriter.bin, binary
   edited it to replace the name of the selected library in 2) with
   the name of my dummy shared library
5) prelinked swriter.bin

Now I save almost a second user time against unprelinked soffice.bin
(in both cases a warm start):

LD_DEBUG=statistics oowriterx
      4807:
      4807:     runtime linker statistics:
      4807:       total startup time in dynamic loader: 24917654 clock cycles
      4807:                 time needed for relocation: 6995827 clock cycles (28.0%)
      4807:                      number of relocations: 0
      4807:           number of relocations from cache: 35372
      4807:             number of relative relocations: 0
      4807:                time needed to load objects: 16634638 clock cycles (66.7%)
      4807:
      4807:     runtime linker statistics:
      4807:                final number of relocations: 13642
      4807:     final number of relocations from cache: 49868

The 35372 number above (which is actually number of prelink
fixups) is still high, but that could go down if the libraries
are properly ordered based on their dependencies (I have not put
any effort into this today) and by decreasing symbol duplication
among libraries.  So, it is 13642 vs. 62756 symbol lookups without
prelinking and 49868 fixups and/or relocations using cached
symbol lookups vs. 121745 relocation using cached symbol lookups.

> 	Well - it's a good idea :-) the problem is that a chunk of OO.o
> infrastructure is designed (mozilla-style) not to allow multiple
> concurrent processes to access it's data structures - pwrt.
> configuration data - so, having a single binary is rather important -
> also; the sheer size of the code is also a factor: ~40Mb to have all
> chart,writer,calc,draw [without underlying libraries] in the same
> module.

And how that matters if there is a single binary or multiple binaries?
I guess the action is try to open/write some socket and if that is successful,
write the commands in, so that the already running program handles it,
if that's unsuccessful, a new program is started.
Now, I doubt you need 37 shared libraries to notify the already running
application, so that could very well be done with a tiny fast starting
application.  The different binaries would only differentiate in the shared
libraries which will never be released on dlclose, plus startup speed.

> 	My other thought was to link as much of the common helper code as
> possible into 1 monster 'liboo.so' library and ensure that this was 1st
> after soffice.bin in the symbol search path - thus very substantially
> shortening the average symbol lookup cost - perhaps by a factor of ~20
> or so.

Sure, that would be certainly useful.  I even tried that several years ago,
but at that point such OOo did not start at all, because many places
in OOo didn't care about ODR at all, the same name was used for completely
different functions/classes.

> 	What did you think of the patch ? ;-)

There is nothing special about weak symbols in this regard, they might
actually be replaced with strong symbols now that gcc/linker has COMDAT
support.  And it is certainly wrong to change the rules for how -Bsymbolic
works, it would need to be completely different switch, but still it
is wrong to key that off STB_WEAK.  ELF has symbol visibility that is designed
for these kind of per-symbol decisions.

	Jakub