Zsh Mailing List Archive
Messages sorted by:
Re: Large LS_COLORS makes auto_cd very slow
- X-seq: zsh-users 16981
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: zsh-users@xxxxxxx
- Subject: Re: Large LS_COLORS makes auto_cd very slow
- Date: Wed, 04 Apr 2012 00:52:36 -0700
- In-reply-to: <CABZhJg-xieMZAOEmbYzSb5T-3O8aLNurvPk=SiXsPGjTpAMg-Q@mail.gmail.com>Comments: In reply to Jesper Nygårds <firstname.lastname@example.org> "Large LS COLORS makes auto cd very slow" (Apr 3, 9:08pm)
- List-help: <mailto:email@example.com>
- List-id: Zsh Users List <zsh-users.zsh.org>
- List-post: <mailto:firstname.lastname@example.org>
- Mailing-list: contact zsh-users-help@xxxxxxx; run by ezmlm
- References: <CABZhJg-xieMZAOEmbYzSb5T-3O8aLNurvPk=SiXsPGjTpAMg-Q@mail.gmail.com>
On Apr 3, 9:08pm, Jesper Nygårds wrote:
} whereas completion after an explicit cd is nearly instantaneous:
} cd /us<tab>
} It seems rather odd to me that coloring would render this so slow. I
} suppose the delay is caused by zsh trying to color some list of
} possible completions, but why would it be so very slow?
/us<tab> as the first word in the buffer is in command position, so is
completing any/all of commands, executables, builtins, functions,
aliases, suffix-aliases, reserved-words, jobs and parameters.
For each of these categories, _setup line 12 rebuilds the value of
the _comp_colors array to add new patterns such that any pattern that
started with '=' gets copied with a prefix matching the tag currently
being tested; e.g. '(commands)=...' or '(jobs)=...'
This is done even for tags that won't have any matches because the
colors array has to be ready for the internals to use when a match is
found, there's no way to "call back" to build it on demand.
The expensive bit is that _comp_colors is declared as a unique array,
so every time it gets rebuilt the resulting 1700+ entries are all
compared against one another to make sure there is no duplication.
Repeat that nine times and it takes a while.
With "cd" in front, it's restricted to directories only, so the array
is only rebuilt once.
Addenda for -workers:
Anybody want to have a stab at creating a vastly more efficient version
of Src/params.c:arrayuniq() ? I came up with a faster way to remove the
duplicate elements, but the problem here is to efficiently determine
that there are no duplicates to remove. Perhaps throw the elements into
a hash table and then make one pass looking up each element.
Messages sorted by: