Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
libzsh overhead, minus the benefits
- X-seq: zsh-workers 20100
- From: ari <edelkind-zsh-workers@xxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxx
- Subject: libzsh overhead, minus the benefits
- Date: Fri, 25 Jun 2004 08:34:31 -0400
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
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
Messages sorted by:
Reverse Date,
Date,
Thread,
Author