Re: Slowness issue with git completion

[Bart Schaefer <schaefer@brasslantern.com>]

Having just watched the CentOS mailing list descend into a morass of
increasingly snarky complaints and increasingly hostile and defensive 
responses, I'd really prefer not to have that happen here.

Suggested improvements are welcome.

Implemented improvements are even more welcome.

Assuming that the lack of any particular improvement is due to anything
other than a lack of either man-hours or of the expertise to devote to
making it, is probably misguided.  Getting offended about that to the
point of saying "if you don't like it, go elsewhere" is also misguided.

With that out of the way:

Specifically with respect to completion functions, it's true that there
has been a tendency to take the concept of "context-sensitivity" to an
extreme.  Quite a few completion functions go to considerable lengths
to not just suggest possible correct answers but to avoid suggesting
any incorrect answers.  Often this introduces inefficiency (cf. the
recent change to _deb_packages, workers/28710).

As was suggested in the _deb_packages thread, a good place to start if
you aren't able to implement an efficiency improvement yourself is to
find the slow code path with the zprof module.  I see someone did that
back in workers/28682 but the paste2.org reference has expired.  I
suspect, though, that as with _deb_packages the answer has little to
do with the way the starting set of files is chosen and everything to
do with zsh's parameter manipulation syntax being too grotty for a
large number of complex string manipulations.

Also as someone noted elsewhere, zsh isn't very efficient at doing
array appends or slices.  Both complex string manipulations and lots
of array slicing/appending are done in __git_files_relative which is
called from _git_files.  Not only that, but it does string ops on the
path prefix on every pass around the "for file in $rawfiles" loop;
that at least could be abstracted.

I suspect that if someone undertook to rewrite __git_files_relative
wholly or partly in something like sed or awk, the whole thing would
be down to ~2 seconds even for a large number of files.  Heck, even
redoing the nested loops to do one multi-element array slice each
instead of many single-element splices might make a huge difference.