Re: Git completion slowness

["Benjamin R. Haskell" <zsh@benizi.com>]

On Thu, 9 Dec 2010, Brett Simmers wrote:

> I asked about this in IRC and got a request to send some details to 
> the mailing list, so here they are -
>
> Whenever I try to use tab completion with a git command, zsh hangs for 
> a few minutes using full cpu before coming back with an answer.  It 
> usually isn't causing much disk activity, just cpu.  The command I try 
> to use most often is "git checkout foo<tab>", where foo is the first 
> few letters of a branch name, but the slowness seems to also happen 
> anywhere else I need to complete a filename or branch/tag name.
>
> Some details of my repository:
> - 96,000 files
> - .git is 17GB
> - Deepest directory nesting in the repository is 15 levels but most 
> files are no deeper than 7 levels
>
> I'm running zsh 4.3.10 with _git from today's CVS.  Host OS is Ubuntu 
> 10.04.1, 6GB of RAM with an Intel Core2Quad 2.4ghz.  My git repo is on 
> an SSD (OSZ Vertex I think), so none of the hardware should be a 
> bottleneck.  Bash-completion on the same setup in the same repo works 
> fine without any delays.

I'm still using the workaround of pre-defining this function in a 
startup script:

function __git_files () {}

That prevents all git file completion, which is the cause of the 
slowness (specifically, _multi_parts completion for filenames).  Recall 
that paths are valid arguments to a `git checkout`.

It does mean that git completion won't ever offer up filenames, which I 
can live with, because:

1) I have <C-x><C-f> bound to filename completion (so I can ^X^F 
complete, if I really don't want to type the name, and it exists on 
disk)

and

2) It prevents pegging a CPU at 100% for minutes.

Prior messages:

See: http://www.zsh.org/mla/users/2010/msg00434.html
and my response at: http://www.zsh.org/mla/users/2010/msg00435.html
original diagnosis of _multi_parts being the cause: http://www.zsh.org/mla/workers/2008/msg01535.html

-- 
Best,
Ben