Re: completion tricks

[Sven Wischnowsky <wischnow@informatik.hu-berlin.de>]

Adam Spiers wrote:

> ...
> 
> That's very instructive; thanks.  Why .zdump not .zcompdump?

As I said, I (now) use 4.0.1-pre2 as my normal shell -- that uses
~/.zdump.  But in at least one terminal I'm always running the latest
development version for testing -- that uses the normal ~/.zcompdump
which makes it easier with `zsh -f' and things like that.  And I can't 
use one dump file for both, because functions may change...

> ...
> 
> > > Also, for this to work, wouldn't I have to include ~/.zsh/comp.zwc in
> > > fpath? 
> > 
> > Right.
> 
> OK.  Presumably it has to come before the normal Completion/* paths?
> I find the ELEMENT.zwc bit of the manual pretty hard to understand.
> 
> When I put it at the head of fpath, memory consumption appears to
> grow from:
> 
> USER       PID %CPU %MEM   VSZ  RSS TTY      STAT START   TIME COMMAND
> adams     1421  0.2  0.7  3092 2052 pts/12   S    16:48   0:00 ..../zsh
> 
> to:
> 
> USER       PID %CPU %MEM   VSZ  RSS TTY      STAT START   TIME COMMAND
> adams     1617  8.0  0.8  3772 2172 pts/3    S    16:50   0:00 ..../zsh
> 
> Why's that?  Startup time is better though, as expected.

That's because the shell has to map the `directory' contained in the
digest file (i.e. the list of function names whose definitions are in
the digest).  Also, your OS may choose to map more pages than are
actually used.  If the digest file is at the end of $fpath, the shell
will first find the definition file, load the function from it and
never touch the digest -- which may result in slightly lower memory
consumption at the beginning.  However, as soon as there is a second
zsh running using the digest file will occupy less memory because the
second shell shares the mapped digest.  Given the different memory
mapping policies one probably can't predict which way to load
functions looks better at the beginning.

> ... [ giving tips about performance in the docs ]
> 
> Sounds good.  So far, we have already mentioned _approximate and
> _correct (I still haven't got round to figuring out the difference
> between the two), and match specs.  Some completions used to be really
> expensive, e.g. _perl_modules, _man, and _rpm, but hopefully the
> caching helps a lot with that.  (Incidentally there are some rough
> edges with the caching mechanism which I *still* haven't got round to
> smoothing.)  Anything else?

_cvs. I'm not sure if we should mention normal completion functions -- 
it could make some people not use the system even if their hardware is 
very well capable of supporting the completion system.


Bye
 Sven

P.S.: _approximate = _correct + _complete.  One could say that
      _approximate expects missing characters at the end of the word
      (and doesn't count them as errors), while _correct thinks that
      the word on the line is thought to be correct -- and checks if
      it is.

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de