zsh-workers
 help / color / mirror / code / Atom feed
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


             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).