From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28063 invoked by alias); 26 Apr 2011 18:46:04 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 29056 Received: (qmail 17543 invoked from network); 26 Apr 2011 18:46:02 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE, SPF_HELO_PASS autolearn=ham version=3.3.1 Received-SPF: none (ns1.primenet.com.au: domain at bewatermyfriend.org does not designate permitted sender hosts) From: Frank Terbeck To: Felipe Contreras Cc: zsh-workers@zsh.org, Nikolai Weibull Subject: Re: Slowness issue with git completion In-Reply-To: (Felipe Contreras's message of "Tue, 26 Apr 2011 21:26:25 +0300") References: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) Date: Tue, 26 Apr 2011 20:43:35 +0200 Message-ID: <87liyw7t0o.fsf@ft.bewatermyfriend.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Df-Sender: 430444 Felipe Contreras wrote: > It's very easy to reproduce: > % git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git > linux > % cd linux > % git log v > > It will take a looong time to figure out anything, specially if not > cached. I think I recall investigating the issue and finding that it's > looking for *all* the files in the git repo. Well yes. This is a known issue. I'm fairly sure that this is due to _multi_parts, which probably doesn't scale for jobs like that. I once gave rewriting all that a shot and ended up with a number of helpers for each "type" of file etc. (like modified or ignored files). While they were significantly quicker than the current code, they were probably still full of bugs and shortcomings. Also, I would have had to rewrite *large* parts of the rest of the completion, which would have been a *major* undertaking. In short: It's a known issue and it's very hard to fix (if only because it is a *lot* of work). Regards, Frank -- In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away. -- RFC 1925