On Fri, Jan 14, 2000 at 06:31:50PM +0200, Stas Bekman wrote:
> Just read the mod_ssl vs. apache_ssl thread at /.org:
> http://slashdot.org/apache/99/12/22/1711203.shtml
> 
> jimjag claims that DSO is slower than static builds at the runtime:
> <QUOTE>
> 
> Q: Why has using DSOs anything to do with run-time performance? I always
> thought using DSOs just slows down the startup. 
> 
> A: Not at all. The code produced with DSOs, as well as the way modules are
> implemented, is less optimal than the non-DSO alternative. If you need
> best performance, avoid DSO.  This is covered in the Apache performance
> docs. 
> 
> </QUOTE>
> 
> What do DSO benefactors have to say :)

This depends on the machine architecture in question - DSO's require
that the machine code produced is relocatable. This is so that a shared
object can be loaded at varying virtual addresses in different
processes. On some register starved machine architectures like x86 this
causes more pressure to load and store registers in memory as one has to
reserve an additional register for getting at your global data. Other
architecures like SGI with MIPS processors or AIX with POWER/PowerPC
processors do not even make the distinction, all code is always
relocatable in their runtime model.

I am not 100% familar with the GCC x86 code generator, but isn't the
penalty mostly for accesses to global data and absolute function calls
outside the module? I would suspect that in a well programmed module the
globals should be very rare, and time critical functions are either
local or called via function pointers, where the penalty does not apply.

One additional point is that all the system libraries are normally used
as shared libraries which also use relocatable code. There are few
people that do really statically link in the system libraries into their
programs (if that is possible at all on the machine in question).

-- 
Jens-Uwe Mager

HELIOS Software GmbH
Steinriede 3
30827 Garbsen
Germany

Phone:          +49 5131 709320
FAX:            +49 5131 709325
Internet:       [EMAIL PROTECTED]

Reply via email to