Re: [PATCH v2] rev-list --disk-usage

Jeff King [off-list ref] writes:

I don't know that it's really worth digging into that much, though it's
quite possible there may be some easy wins by optimizing those memcpy
calls. E.g., I'm not sure if the compiler ends up inlining them or not.
If it doesn't realize that the_hash_algo->rawsz is only ever "20" or
"32", we could perhaps help it along with specialized versions of
hashcpy(). If somebody does want to play with it, this patch may make a
good testbed. :)

Yuck.  That reminds me of the adventure Shawn he made in the Java
land benchmarking which one among int[5], int a,b,c,d,e, char[40] is
the most efficient way (both storage-wise and performance-wise) to
store SHA-1 hash.  I wish we didn't have to go there.

It indeed is an interesting, despite a bit sad, observation that
even with a good precomputed information, an overly heavy interface
can kill potential performance benefit.

Thanks.