* Re: optimisations
@ 1999-12-14 9:40 Sven Wischnowsky
0 siblings, 0 replies; 3+ messages in thread
From: Sven Wischnowsky @ 1999-12-14 9:40 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: optimisations
@ 1999-12-16 10:07 Sven Wischnowsky
0 siblings, 0 replies; 3+ messages in thread
From: Sven Wischnowsky @ 1999-12-16 10:07 UTC (permalink / raw)
To: zsh-workers
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.) I notice that $history gets set to the whole
> history; what uses that? I have HISTSIZE=5000 so this variable is
> fairly sizeable!
One thing I forgot to say: we could easily add a boolean style `cache'
which says if caching should be done in a certain context or
not. Leaving it to the user to decide if he prefers speed or a small
memory footprint.
Bye
Sven
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
^ permalink raw reply [flat|nested] 3+ messages in thread
[parent not found: <Liam.945065738.543685.31995.772540271@fizz>]
end of thread, other threads:[~1999-12-16 10:07 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-12-14 9:40 optimisations Sven Wischnowsky
-- strict thread matches above, loose matches on Subject: below --
1999-12-16 10:07 optimisations Sven Wischnowsky
[not found] <Liam.945065738.543685.31995.772540271@fizz>
[not found] ` <991213182445.ZM11778@candle.brasslantern.com>
1999-12-13 19:24 ` optimisations Adam Spiers
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).