Jeff King wrote: > FWIW, it's not 10%. The best I measured was ~4% on a very > hashcmp-limited operation, and I suspect even that may be highly > dependent on the compiler. We might be able to improve more by > sprinkling more asserts around, but there are 75 mentions of > the_hash_algo->rawsz. I wouldn't want to an assert at each one. > > I don't mind doing one or a handful of these asserts as part of v2.19 if > we want to try to reclaim those few percent. But I suspect the very > first commit in any further hash-transition work is just going to be to > rip them all out.
I was thinking just hashcmp and hashcpy. Ideally such a change would come with a performance test to help the person writing that very first commit. Except we already have performance tests that capture this. ;-) For further hash-transition work, I agree someone may want to revert this, and I don't mind such a revert appearing right away in "next". And it's possible that we might have to do the equivalent of manual template expansion to recover the performance in some performance-sensitive areas. Maybe we can get the compiler to cooperate with us in that and maybe we can't. That's okay with me. Anyway, I'll resend your patch with a commit message added some time this evening. Thanks, Jonathan
