Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: zsh-3.0-pre1: speed up the "list-choices" etc.
- X-seq: zsh-workers 1565
- From: Zefram <A.Main@xxxxxxxxxxxxxxxxx>
- To: suzuki@xxxxxxxxxxxxxx (SUZUKI Hisao)
- Subject: Re: zsh-3.0-pre1: speed up the "list-choices" etc.
- Date: Mon, 8 Jul 1996 08:30:54 +0100 (BST)
- Cc: zsh-workers@xxxxxxxxxxxxxxx
- In-reply-to: <9607080038.AA01466@xxxxxxxxxxxxxxxxxxxxxxxxx> from "SUZUKI Hisao" at Jul 8, 96 09:38:47 am
> Certainly it is mainly because of the terminal and its
>device interface, it is possible to speed up the "list-choices"
>etc. by improving the z-shell. It is `nicezputs' in Src/utils.c
>that displays the string of completion list, and its current
>implementation calls `fputs' for each character in the string.
The reason it does that (and I can answer with authority here as I
originated that code) is that fputs(), being part of stdio, should
buffer output. It is consequently not really significant how many
times it actually gets called. Had we been dealing with unbuffered
output, I would have added some explicit buffering.
>Modifying Src/utils.c so that `nicezputs' calls `fputs' once for
>all characters, the speed becomes tolerable even on the slow
>terminal.
If that's the case, then it indicates something more fundamental is
wrong. I suspect that it's a problem with your system. In my
experience, zsh's completion lists appear at pretty much the speed the
terminal is set to (9600 baud for me at the moment, and that's
normal). zsh doesn't disable buffering on the tty output stream at any
point -- it uses fflush() appropriately.
-zefram
Messages sorted by:
Reverse Date,
Date,
Thread,
Author