Re: Slowness issue with git completion

[Nikolai Weibull <now@xxxxxxxx>]

On Wed, Apr 27, 2011 at 06:19, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:

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

Let’s instead remove it.

The attached patch seems to speed up matching a lot, while maintaining
all functionality.  There might be cases that I haven’t considered.
Please review.

Another adjustment is that we could join the calls to git rev-parse
into one call:

gitcdupandprefix=${$(_call_program git-cdup-and-prefix git rev-parse
--show-cdup --show-prefix 2>/dev/null)/$'\n'}

to decrease the fork count as well, which makes a difference on
Cygwin.  This won’t be quite correct, however, as it won’t work for
prefixes with newlines in them.  Git-rev-parse sadly doesn’t take the
-z option.

Also, Bart, supplying -f to _multi_parts here doesn’t seem to have any
effect on match highlighting.  Directories are shown the same as
files.  This was something I asked about a long time ago that we were
going to look at at a later date.  Perhaps that date has come?

Attachment: git.patch
Description: Binary data