git completion is really slow for some git commands.

[Brice Figureau <brice+zsh@daysofwonder.com>]

Hi,

I'm a long time user of zsh, and I've always been really pleased by its
superior completion system. Right now, I'm running lenny debian package
of 4.3.6.

Unfortunately git completion, although working fine, is extremely slow
as soon as you have a moderately sized git repository. In my case, my
checkout have 13000 files and about 6000 commits.

git log <TAB> takes about 15s using 100% CPU to complete on my 2.4GHZ P4
computer. OK, that's now an old computer, but I find that a little bit
slow to just sort/split 13000 strings.

It all boils down to the following chain of events:
 * git log completion uses __git_files

 * _git_files uses "git ls-files". In itself ls-files on this repository
on cold cache takes about 70ms (which is short, compared to the 15s of
the whole thing).

 * the result of git ls-files is splitted by \0 and stored in a shell
array. This operation takes about 350ms. That's still fast compared to
the 15s of the whole execution time. Note: that's not as fast we would
think it could be.

 * this shell array is then passed to _multi_parts for path splitting of
each element. This is this operation that takes age. As soon as I change
the _multi_parts code to just call a naive compadd and return, the
completion is (almost) immediate, and seems to work fine.

I understand that the issue might be that git ls-files returns _all_ the
files present in the index (ie not only the first level, it recurses the
hierarchy). 

Now, I'm really a zsh completion newbie, so I still fail to see how to
optimize the _git_files operation. Does anybody have an idea to speed up
the multi_parts thing? And Is it really needed?

Many thanks for the answers,
-- 
Brice Figureau <brice+zsh@daysofwonder.com>