On Thu, May 30, 2013 at 7:29 PM, Alex Bennée <kernel-hac...@bennee.com> wrote:
> 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.184.108.40.206 [.] 0xe0ec
> 10.39% git libz.so.220.127.116.11 [.] 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?
If I'm not mistaken, commits are never deltified. They are usually
small and packed close together for better I/O patterns. If you really
just read hundreds of commits, it can't take that long. Maybe some
code paths accidentally open a tree, a blob or something..
Can you try setting core.logpackaccess to a path on and rerun
describe? Jugding from the code (I never actually tried it), it'll
create a file at the given path with the accessed pack offsets. You
can check what offset corresponds to what object with verify-pack -v.
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