Re: Large LS_COLORS makes auto_cd very slow

[Bart Schaefer <schaefer@brasslantern.com>]

On Apr 3,  9:08pm, Jesper Nygårds wrote:
}
} /us<tab>
} 
} 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.