[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Fwd: Re: BLAST+ speed & build issues



On Thu, Aug 04, 2011 at 12:02:25PM +0200, Olivier Sallou wrote:
> For info, executable is quite large 11MB (static) vs 2M (dynamic).

The 11MB probably contains a whole bunch of libraries instead,
making it larger.  I don't see how this is relavant.

> Dynamic build exe is linked against:
> osallou@debiansid:/tmp/ncbi-blast-2.2.25+-src/debian/ncbi-blast+/usr/bin$ ldd
> /usr/bin/blastx
>     linux-vdso.so.1 =>  (0x00007fffb01a8000)
>     libblastinput.so => /usr/lib/ncbi-blast+/libblastinput.so
> (0x00007f06d9572000)
[...lots of blast libs...]

> For a simple "-h" call, here is a benchmark:

Like others have pointed out, this is not a useful benchmark.
You're basicly testing the startup time of your application.  When
you start an applications that dynamic linker has to resolv
symbols and relocations.  This takes time which for the static
version was done at link time.  Having more libraries it needs to
check for the symbol means it will take longer.

What can help is that you reduce the total amount of symbols that
it needs to check be only exporting the symbols you need from the
shared libraries.  There are various methods for that.

The basic 3 methods I know:
- Making things as much as possible static.
- Using symbol visibility: tell gcc which symbols should be visible.
- Using a linker map to only export those that should be visible.


Kurt


Reply to: