On 4 April 2012 09:52, Bart Schaefer wrote: > On Apr 3,  9:08pm, Jesper Nygårds wrote: > } > } /us > } > } whereas completion after an explicit cd is nearly instantaneous: > } > } cd /us > } > } 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 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. I wonder if the attached patch does what you want here. It is fairly untested and incomplete as I have not been able to find out how to make sure that search.h gets included. -- VZ