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

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 9, 2021, 21:14 UTC
Message-ID: <xmqq8s7x0wra.fsf@gitster.c.googlers.com>
In-Reply-To: <YCJtbmaguIW+YeAs@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 7 quoted lines

> 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.