From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.auc.dk
Subject: Re: excessive memory usage?
Date: Wed, 19 Jul 2000 15:07:44 +0200 (MET DST) [thread overview]
Message-ID: <200007191307.PAA10850@beta.informatik.hu-berlin.de> (raw)
In-Reply-To: Clint Adams's message of Wed, 19 Jul 2000 04:59:10 -0400
I had seen this message on the debian list, but didn't have the time
to reply yet.
Clint Adams wrote:
> I received this bug report last week. Due to lack of time,
> I haven't had a chance to look into it thoroughly, but I
> just tried it out, and it did suck up (rather slowly) about
> 42 megs (temporarily) before it finally completed.
>
> I'm guessing that this happens during compadd. So is this
> evidence of some inefficiency or is all that memory necessary?
As Peter already pointed out the problem is really that the function
passes down huge arrays and has to copy them several times and the
solution is to use the -a option to compadd. Some more comments below.
> As for the second issue, I grabbed a vera.index that is probably
> more recent (it has 9109 lines), and zsh happily completes from all
> of the 6380 unique values. I assume that his 7617->5996 effect
> is also from duplicate values.
This is what I was thinking, too.
> ...
>
> I have ~/.zshfunc directory in $fpath, and I made _dict file and put it
> there. That file contained:
>
> #compdef dict
> _arguments '*:dictword:_dictwords'
If there isn't anything else in this file, then we don't need to use
_arguments. Because calling _arguments with only one `*:...' spec and
no options, no other arguments specs is the same as doing the action
from the `*:...' spec. Only slower.
> ...
>
> I also tried this to define $dictwords:
>
> (( $+_cache_dictwords )) || \
> : ${(A)_cache_dictwords:=${${(f)"$(</usr/share/dictd/wn.index)"}%%[ ]*}}
>
> dictwords=("$_cache_dictwords[@]")
For things that change as seldom as dictionaries, caching is
definetely a good idea. But no need to copy the cache-array into yet
another local array -- that would cause some more unnecessary
allocation and copying. Just use `compadd ... -a _cache_dictwords'.
And if this is ever intended to be included in the distribution, the
-M should be removed, there are enough styles around to give users the
possibility to define them if they want them. In a simple personal
completion function, of course...
Bye
Sven
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
next reply other threads:[~2000-07-19 13:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-07-19 13:07 Sven Wischnowsky [this message]
2000-07-19 17:30 ` Clint Adams
2000-07-20 6:14 ` Andrej Borsenkow
-- strict thread matches above, loose matches on Subject: below --
2000-07-19 8:59 Clint Adams
2000-07-19 9:13 ` Peter Stephenson
2000-07-19 17:16 ` Clint Adams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200007191307.PAA10850@beta.informatik.hu-berlin.de \
--to=wischnow@informatik.hu-berlin.de \
--cc=zsh-workers@sunsite.auc.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).