On Sat, May 11, 2013 at 1:22 AM, Jeff King <p...@peff.net> 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...
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