Re: Performance issue of 'git branch'

From: George Spelvin <linux@horizon.com>
Date: Jul 26, 2009, 23:21 UTC
Message-ID: <20090726232154.29594.qmail@science.horizon.com>

Show 7 quoted lines

> It's a bit sad, since the _only_ thing we load all of libcrypto for is the 
> (fairly trivial) SHA1 code. 
>
> But at the same time, last time I benchmarked the different SHA1 
> libraries, the openssl one was the fastest. I think it has tuned assembly 
> language for most architectures. Our regular mozilla-based C code is 
> perfectly fine, but it doesn't hold a candle to assembler tuning.

Actually, openssl only has assembly for x86, x86_64, and ia64. Truthfully, once you have 32 registers, SHA1 is awfully easy to compile near-optimally.

Git currently includes some hand-tuned assembly that isn't in OpenSSL:
- ARM (only 16 registers, and the rotate+op support can be used nicely)
- PPC (3-way superscalar *without* OO execution benefits from careful
  scheduling)

Further, all of the core hand-tuned SHA1 assembly code in OpenSSL is by Andy Polyakov and is dual-licensed GPL/3-clause BSD *in addition to* the OpenSSL license. So we can just import it:

See http://www.openssl.org/~appro/cryptogams/ and http://www.openssl.org/~appro/cryptogams/cryptogams-0.tar.gz

(Ooh, look, he has PPC code in there, too. Does anyone with a PPC machine want to compare it with Git's?)

It'll take some massaging because that's just the core SHA1_Transform function and not the wrappers, but it's hardly a heroic effort.

I'm pretty deep in the weeds at $DAY_JOB and can't get to it for a while, but would a patch be appreciated?