From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7958 invoked from network); 13 Oct 2008 01:04:37 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL autolearn=unavailable version=3.2.5 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 13 Oct 2008 01:04:37 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 44776 invoked from network); 13 Oct 2008 01:04:02 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 13 Oct 2008 01:04:02 -0000 Received: (qmail 14244 invoked by alias); 13 Oct 2008 01:03:23 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 25866 Received: (qmail 14141 invoked from network); 13 Oct 2008 01:03:18 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 13 Oct 2008 01:03:18 -0000 Received: from uucp.gnuu.de (unknown [83.246.114.63]) by bifrost.dotsrc.org (Postfix) with ESMTP id 29E4980524C2 for ; Mon, 13 Oct 2008 03:03:02 +0200 (CEST) Received: by uucp.gnuu.de (Postfix, from userid 10) id 64A5F4880D8; Mon, 13 Oct 2008 03:03:02 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.5.2 uucp.gnuu.de 64A5F4880D8 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gnuu.de; s=banki; t=1223859782; i=@alea.gnuu.de; bh=A9FFbQbccw0yeALqxYiSG5r+sTMwTBd5c XvmuBrQY3o=; h=To:From:Subject:Date:Message-ID:References: Mime-Version:Content-Type:Content-Transfer-Encoding:Sender; b=k66S cC9Zom/fTNCcZr092ytoDKVTc9mz0kcvbcr3dXbraiz6c2HTA9Nx+7PMCvHjNrzsVLW R4oTNbi8lreHyYkxoHjMPRebEP0vQMXP0vE//LG1z1rbTs8CHbkYqiJ8FCUebRPnWkT r5LvzDLFC7UKERdk0CMa2411Br73pHAEs= Received: from news by alea.gnuu.de with local (Exim 4.63) (envelope-from ) id 1KpBgq-0006Sm-VL for zsh-workers@sunsite.dk; Mon, 13 Oct 2008 02:53:41 +0200 To: zsh-workers@sunsite.dk Path: not-for-mail From: =?UTF-8?Q?J=C3=B6rg?= Sommer Newsgroups: local.mailinglist.zsh Subject: [PATCH] Re: git completion is really slow for some git commands. Date: Mon, 13 Oct 2008 00:53:40 +0000 (UTC) Message-ID: References: <1223557300.563.31.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Trace: alea.gnuu.de 1223859220 24846 192.168.0.5 (13 Oct 2008 00:53:40 GMT) X-Complaints-To: usenet@alea.gnuu.de User-Agent: slrn/0.9.9 (Linux) Sender: news X-Virus-Scanned: ClamAV 0.92.1/8414/Sun Oct 12 05:30:50 2008 on bifrost X-Virus-Status: Clean Hello Brice, Brice Figureau wrote: > 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 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. Can you try this patch? It doesn't change anything if you didn't specify anything, i.e. git log -- takes still very long. But it optimizes the case when you specify anything. Try git log -- some/thing. commit e985683fe8d805228ad88903261f20181de23f1e Author: Jörg Sommer Date: Mon Oct 13 01:58:03 2008 +0200 Prefilter the completion for _multi_parts The _multi_parts function consumes very much time, if the array with the possible completions is large. This happens often in large git repositories like the kernel git repository. To reduce the workload of _multi_parts filter out does entries from the array, they aren't possible completions. When the user specifies the path foo/bar only consider paths matching the pattern foo*/bar*. diff --git a/Completion/Unix/Command/_git b/Completion/Unix/Command/_git index c617613..5fd637a 100644 --- a/Completion/Unix/Command/_git +++ b/Completion/Unix/Command/_git @@ -2761,6 +2761,7 @@ __git_files () { files=(${(ps:\0:)"$(_call_program files git ls-files -z $ls_opts $opts 2>/dev/null)"}) __git_command_successful || return + [[ -n $PREFIX ]] && files=${(M)files:#${~PREFIX//\//*/}*} _wanted files expl 'index file' _multi_parts $@ - / files } @@ -2859,6 +2860,7 @@ __git_tree_files () { fi local expl + [[ -n $PREFIX ]] && tree_files=${(M)tree_files:#${~PREFIX//\//*/}*} _wanted files expl 'tree file' _multi_parts -f $@ -- / tree_files } Question to everybody else: Should such a filter go to _multi_parts itself? Bye, Jörg. -- Alles, wovor wir Angst haben müssen, ist die Angst selbst. (Franklin D. Roosevelt)