From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20777 invoked from network); 14 Dec 1999 09:40:24 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 14 Dec 1999 09:40:24 -0000 Received: (qmail 15375 invoked by alias); 14 Dec 1999 09:40:17 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 9034 Received: (qmail 15368 invoked from network); 14 Dec 1999 09:40:16 -0000 Date: Tue, 14 Dec 1999 10:40:15 +0100 (MET) Message-Id: <199912140940.KAA29168@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: Adam Spiers's message of Mon, 13 Dec 1999 19:24:57 +0000 Subject: Re: optimisations Adam Spiers wrote: > Bart Schaefer (schaefer@candle.brasslantern.com) wrote: > > The last one is a bit unfortunate, but just "compinit" (without even > > trying any completions yet) adds half a megabyte to the RSS of zsh on > > my system, and it only goes up from there as functions autload and > > start caching their results in shell variables. > > This reminds me. Not only does the completion system make the > environment, and hence memory usage large, but it slows startup down. > Are there any significant optimisations which can be done? Maybe > caching some of the large associative arrays to disk in (say) DBM > format so that several shells can share them? I know this is already > done in .zcompdump ... any others? (I've been meaning to do this for > _man, actually.) Which would slow things down... but I haven't tried so I don't know how much. > I notice that $history gets set to the whole > history; what uses that? I have HISTSIZE=5000 so this variable is > fairly sizeable! It doesn't really get set to it. $history (and $historywords) are implement by function which make them look like arrays. Memory is only allocated for them when they are really used -- and that is heap memory which will be freed soon. But yes, heavy usage of it may be slow and expensive... feel free to write a better interface (or improve the current implementation). Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de