Hi Peff, On Fri, 10 Feb 2017, Jeff King wrote: > On Thu, Feb 09, 2017 at 11:27:49PM +0100, Johannes Schindelin wrote: > > > From: Jeff Hostetler <jeffhost@xxxxxxxxxxxxx> > > > > Use OpenSSL's SHA-1 routines rather than builtin block-sha1 routines. > > This improves performance on SHA1 operations on Intel processors. > > > > OpenSSL 1.0.2 has made considerable performance improvements and > > support the Intel hardware acceleration features. See: > > https://software.intel.com/en-us/articles/improving-openssl-performance > > https://software.intel.com/en-us/articles/intel-sha-extensions > > > > To test this I added/staged a single file in a gigantic repository > > having a 450MB index file. The code in read-cache.c verifies the > > header SHA as it reads the index and computes a new header SHA as it > > writes out the new index. Therefore, in this test the SHA code must > > process 900MB of data. Testing was done on an Intel I7-4770 CPU @ > > 3.40GHz (Intel64, Family 6, Model 60) CPU. > > I think this is only half the story. A heavy-sha1 workload is faster, > which is good. But one of the original reasons to prefer blk-sha1 (at > least on Linux) is that resolving libcrypto.so symbols takes a > non-trivial amount of time. I just timed it again, and it seems to be > consistently 1ms slower to run "git rev-parse --git-dir" on my machine > (from the top-level of a repo). > > 1ms is mostly irrelevant, but it adds up on scripted workloads that > start a lot of git processes. You know my answer to that. If scripting slows things down, we should avoid it in production code. As it is, scripting slows us down. Therefore I work slowly but steadily to get rid of scripting where it hurts most. Ciao, Dscho