In the last episode (Jul 16), Jeremy Zawodny said:
> On Mon, Jul 07, 2003 at 10:57:52AM -0500, Dan Nelson wrote:
> > In the last episode (Jul 07), Nils Valentin said:
> > > Thank you for the superfast reply. I actually was looking for
> > > other information. I understood the actual feature difference of
> > > the standard and f.e max version. Sorry if this didnt came out
> > > so clear. I will try to make it clearer.
> > >
> > > My question was more aiming at what advantages the dynamically
> > > linking or the statically linking have (except the memory usage
> > > of course). I was thinking when given 2 times the same versions
> > > once linked statically and once linked dynamically which one
> > > would have which advantages in regards to performance,
> > > reliability etc. ?
> > You can't call dlopen() on a statically-linked binary, so you can't use
> > UDFs. On the other hand, static binaries usually run ~20% faster.
> That seems like a high number. Have you actually seed that much of a
I have, but I haven't tested long-lived monolithic programs like mysql.
The big penalties you pay for shared linking are much higher startup
overhead, the requirement that your shared libraries be compiled with
-fPIC (thus losing a register), and the possible cost of a lookup in a
jump table whan calling functions from one library into another.
Startup time isn't a problem for mysql, and the server code isn't built
out of shared libraries, so a statically-linked mysql might not really
buy you that much.
talk a bit about the penalties of using shared libs, but they're really
from the point of view of the library author and relative speeds of
shared libs vs static libs. A dynamically-linked program that spends
most of its time in its own code (as opposed to doing function calls to
CPU-intensive routines in libraries) will probably not see much of a