On Sat, May 11, 2013 at 1:22 AM, Jeff King <peff@xxxxxxxx> wrote: > On Sat, May 11, 2013 at 12:11:05AM -0700, David Aguilar wrote: > >> > Does this perform better or worse than just setting >> > BLK_SHA1=YesPlease? I'd naively think it could go either way: on one >> > hand adding another library dependency can slow down startup, and on >> > the other hand the implementation may or may not be optimized better >> > than the generic block-sha1/ implementation. >> >> Pretty much identical. >> >> Here are the timings (I should probably read t/perf/README and get >> better numbers): >> >> Best of ten >> $ time git rev-list --all --objects >/dev/null >> [...] > > I'm not sure that's a great test of sha1 performance. It will hash the > commit and tree objects it loads during the traversal, but that time is > almost certainly dwarfed by zlib inflation and by lookup_object. > > Adding "--verify-objects" would sha1 the blobs, too, which might be more > reasonable (or running "git fsck"). Something like "git add" on a large > blob would also be a good test. Thanks. Here are the numbers with --verify-objects: $ time git rev-list --all --objects --verify-objects >/dev/null # CommonCrypto 32.24s user 4.65s system 99% cpu 37.098 total # master 33.00s user 4.68s system 99% cpu 37.852 total # BLK_SHA1 54.17s user 4.67s system 99% cpu 58.928 total Doing BLK_SHA1 seems like less of a good idea now, so I think my latest re-roll might be the way to go... -- David -- 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