Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758276Ab2J0Nd7 (ORCPT ); Sat, 27 Oct 2012 09:33:59 -0400 Received: from mail-ea0-f174.google.com ([209.85.215.174]:39608 "EHLO mail-ea0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758025Ab2J0Nd5 (ORCPT ); Sat, 27 Oct 2012 09:33:57 -0400 Date: Sat, 27 Oct 2012 15:33:52 +0200 From: Ingo Molnar To: David Ahern , git@vger.kernel.org Cc: Arnaldo Carvalho de Melo , linux-kernel@vger.kernel.org, Andrew Vagin , Borislav Petkov , David Howells , Frederic Weisbecker , Jiri Olsa , Namhyung Kim , Paul Mackerras , Peter Zijlstra , Stephane Eranian , Steven Rostedt , arnaldo.melo@gmail.com, Arnaldo Carvalho de Melo Subject: 'git describe' is very slow on development trees with lots of commits Message-ID: <20121027133352.GB30001@gmail.com> References: <1351261913-28250-1-git-send-email-acme@infradead.org> <20121026145451.GA14379@gmail.com> <508AA709.7010202@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <508AA709.7010202@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3077 Lines: 89 (Cc:-ed the Git development list.) * David Ahern 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/