git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: David Ahern <dsahern@gmail.com>, git@vger.kernel.org
Cc: Arnaldo Carvalho de Melo <acme@infradead.org>,
	linux-kernel@vger.kernel.org, Andrew Vagin <avagin@openvz.org>,
	Borislav Petkov <bp@amd64.org>,
	David Howells <dhowells@redhat.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Jiri Olsa <jolsa@redhat.com>, Namhyung Kim <namhyung@kernel.org>,
	Paul Mackerras <paulus@samba.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Stephane Eranian <eranian@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	arnaldo.melo@gmail.com,
	Arnaldo Carvalho de Melo <acme@redhat.com>
Subject: 'git describe' is very slow on development trees with lots of commits
Date: Sat, 27 Oct 2012 15:33:52 +0200	[thread overview]
Message-ID: <20121027133352.GB30001@gmail.com> (raw)
In-Reply-To: <508AA709.7010202@gmail.com>


(Cc:-ed the Git development list.)

* David Ahern <dsahern@gmail.com> wrote:

> PERF-VERSION-GEN and specifically the git commands are the 
> cause of more delay than the config checks, especially when 
> doing the build in a VM with the kernel source on an NFS 
> mount.

Yes, I have noticed that too.

So, the problem is that we use 'git describe' on the kernel tree 
to generate the version string, which is very, very slow if we 
are far away from any tagged release - which is the case for the 
-tip tree:

 comet:~/tip> perf stat --null --repeat 3 git describe
 v3.7-rc2-2007-g83e8223
 v3.7-rc2-2007-g83e8223
 v3.7-rc2-2007-g83e8223

'git describe' is much faster if we are on or near to a tag:

 $ git checkout v3.6
 $ perf stat --null --repeat 3 git describe
 v3.6
 v3.6
 v3.6

 Performance counter stats for 'git describe' (3 runs):

       0.020171640 seconds time elapsed                                          ( +-  3.64% )

 $ git checkout b34e5f55a1e6

 $ perf stat --null --repeat 3 git describe
 v3.6-41-gb34e5f5
 v3.6-41-gb34e5f5
 v3.6-41-gb34e5f5

 Performance counter stats for 'git describe' (3 runs):

       0.155603676 seconds time elapsed                                          ( +-  0.23% )

The cost on this pretty fast machine is about 1 msecs per commit 
- which adds up to about 2.5 seconds during much of the 
development cycle.

So maybe we should be using a different version string, for 
example, instead of:

 v3.7-rc2-2007-g83e8223

this would be perfectly fine:

 v3.7-rc2-g83e8223

the 'commit count' is informative but not essential - and in 
counting the number of off-tag commits is where much of the 
overhead is:

#
# Overhead  Command       Shared Object                                      Symbol
# ........  .......  ..................  ..........................................
#
    39.79%      git  libz.so.1.2.5       [.] 0x000000000000c1fe                    
    26.39%      git  libz.so.1.2.5       [.] inflate                               
    22.42%      git  git                 [.] 0x000000000009bd1e                    
     2.99%      git  libz.so.1.2.5       [.] adler32                               
     1.23%      git  libc-2.15.so        [.] _int_malloc                           
     0.72%      git  libc-2.15.so        [.] __GI_____strtoull_l_internal          
     0.67%      git  libc-2.15.so        [.] _int_free                             
     0.62%      git  libc-2.15.so        [.] malloc_consolidate                    
     0.54%      git  [kernel.kallsyms]   [k] clear_page_c                          
     0.32%      git  [kernel.kallsyms]   [k] page_fault                            

So by switching to the shorter version string that still embedds 
the tag and the exact sha1 we'd be able to run this script a 
*lot* faster.

Thanks,

	Ingo

       reply	other threads:[~2012-10-27 13:34 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1351261913-28250-1-git-send-email-acme@infradead.org>
     [not found] ` <20121026145451.GA14379@gmail.com>
     [not found]   ` <508AA709.7010202@gmail.com>
2012-10-27 13:33     ` Ingo Molnar [this message]
2012-10-31 17:52       ` 'git describe' is very slow on development trees with lots of commits Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20121027133352.GB30001@gmail.com \
    --to=mingo@kernel.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@infradead.org \
    --cc=acme@redhat.com \
    --cc=arnaldo.melo@gmail.com \
    --cc=avagin@openvz.org \
    --cc=bp@amd64.org \
    --cc=dhowells@redhat.com \
    --cc=dsahern@gmail.com \
    --cc=eranian@gmail.com \
    --cc=fweisbec@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=namhyung@kernel.org \
    --cc=paulus@samba.org \
    --cc=rostedt@goodmis.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).