On Thu, May 30, 2013 at 7:29 PM, Alex Bennée <kernel-hacker@xxxxxxxxxx> 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.1.2.3.4 [.] 0xe0ec > 10.39% git libz.so.1.2.3.4 [.] 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. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html