Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: Git completion slowness



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



Messages sorted by: Reverse Date, Date, Thread, Author