libzsh overhead, minus the benefits

libzsh overhead, minus the benefits

[ari]

The only potential reason that i see for having all zsh functionality in
libzsh.so, while keeping the zsh binary more or less a stub into the
library, is the reuse of shared memory mappings.  However, and correct
me if i'm wrong, the zsh shell is the only program that is meant to use
this library.  The idea seems to be that multiple instances of the
binary will run with a minimal amount of redundant code, saving memory
when many zsh processes are running simultaneously.

There is an error in this reasoning.  Modern systems offer shared
executable code mappings, so that if multiple instances of a binary are
running simultaneously, the majority of the code in memory will be
shared between processes.  Due to dynamic loader and function relocation
(indirection) overhead, using libzsh.so actually causes each running zsh
process to consume _more_ memory than if the code were compiled into the
original binary.  The indirection will also cause a slight increase in
processing time, as loading the library will cause a slight increase in
execution time.  In these cases, using a dynamic library only helps when
multiple, different executables require use of the same family of
functions.

Perhaps the use of libzsh.so should be reconsidered?

ari

Re: libzsh overhead, minus the benefits

[Geoff Wing]

ari <edelkind-zsh-workers@episec.com> typed:
: There is an error in this reasoning.

Normally.  And then comes MSWindows 95/98 (and who knows what else).  But yes,
for most systems (with modern VM systems), it's an incorrect method of trying
to save memory use.

Regards,
Geoff

Re: libzsh overhead, minus the benefits

[Bart Schaefer]

On Fri, 25 Jun 2004, ari wrote:

> The only potential reason that i see for having all zsh functionality in 
> libzsh.so, while keeping the zsh binary more or less a stub into the 
> library, is the reuse of shared memory mappings.

No; that has nothing to do with it.

On some operating systems to which zsh has been ported, it is not possible 
to have dynamic (relocatable, if I recall correctly) symbol linkage from a 
non-dynamic library to a dynamic one.  That is, it's first necessary to 
load at least one library via a static linkage, and then that library can 
load other libraries at run time.

So nearly all of zsh was put into a loadable library so that the zmodload 
command would work, and could be programmed in nearly the same way, on all 
the platforms where zsh compiles.