From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4982 invoked from network); 26 Jun 2004 11:12:22 -0000 Received: from odin.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.85) by ns1.primenet.com.au with SMTP; 26 Jun 2004 11:12:22 -0000 Received: (qmail 27627 invoked from network); 26 Jun 2004 12:04:00 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 26 Jun 2004 12:04:00 -0000 Received: (qmail 25805 invoked by alias); 26 Jun 2004 10:44:41 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 20100 Received: (qmail 25762 invoked from network); 26 Jun 2004 10:44:40 -0000 Received: from odin.dotsrc.org (HELO a.mx.sunsite.dk) (@130.225.247.85) by sunsite.dk with SMTP; 26 Jun 2004 10:44:40 -0000 Received: (qmail 13440 invoked from network); 26 Jun 2004 11:20:31 -0000 Received: from episec.com (69.55.237.141) by a.mx.sunsite.dk with SMTP; 26 Jun 2004 11:20:29 -0000 Received: (qmail 28108 invoked by uid 1024); 25 Jun 2004 12:34:31 -0000 Date: Fri, 25 Jun 2004 08:34:31 -0400 From: ari To: zsh-workers@sunsite.dk Subject: libzsh overhead, minus the benefits Message-ID: <20040625123431.GR96475@episec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 on a.mx.sunsite.dk X-Spam-Level: X-Spam-Status: No, hits=0.7 required=6.0 tests=DATE_IN_PAST_12_24 autolearn=no version=2.63 X-Spam-Hits: 0.7 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