The repo is a fairly hairy one as it includes two historically
un-related but content related repos which I'm the process of
cherry-picking stuff across.
11:58 ajb@sloy/x86_64 [work.git] >git count-objects -v
This was after a repack which did have slight negative effect on
performance. The pack file is:
13:27 ajb@sloy/x86_64 [work.git] >ls -lh ./.git/objects/pack/*
-r--r--r-- 1 ajb cvs 11M May 30 11:56
-r--r--r-- 1 ajb cvs 1.9G May 30 11:56
I ran perf on it and the top items in the report where:
41.58% git libcrypto.so.1.0.0 [.] 0x6ae73
33.96% git libz.so.188.8.131.52 [.] 0xe0ec
10.39% git libz.so.184.108.40.206 [.] adler32
2.03% git [kernel.kallsyms] [k] clear_page_c
So I'm guessing it's spending a lot of non-cache efficient time
un-packing and processing the deltas?
On 30 May 2013 12:48, John Keeping <j...@keeping.me.uk> wrote:
> On Thu, May 30, 2013 at 11:38:32AM +0100, Alex Bennée wrote:
>> One factor might be the size of my repo (.git is around 2.4G). Could
>> this just be due to computational cost of searching through large
>> packs to walk the commit chain? Is there any way to make this easier
>> for git to do?
> What does "git count-objects -v" say for your repository?
> You may find that performance improves if you repack with "git gc
Alex, homepage: http://www.bennee.com/~alex/
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html