From: Junio C Hamano Date: Tue, 26 Aug 2025 15:34:00 GMT Subject: Re: [PATCH] describe: use khash in finish_depth_computation() Message-ID: In-Reply-To: <20250826042607.GA995491@coredump.intra.peff.net> Jeff King writes: > OK, maybe I am just holding it wrong. I think I may have mistakenly been > using the wrong timing for my baseline (maybe --date-order instead of > --author-date-order; the latter is _way_ more expensive because we have > to open the commits to parse the author date). True. And the numbers below are much more believable ;-) > Here's a more apples-to-apples comparison using hyperfine. On git.git: > ... > So a little slowdown, but within the run-to-run noise. And on linux.git: > ... > A little more measurable there. Those numbers are more in line with what > I was expecting. > ... > I'm not sure what it all means, though. 6% is enough that it is > probably worth keeping a custom data type like slab around. > Though it would be nice to have a data type that worked on all > object types and didn't necessarily use a ton of memory. Yup, a short version of it is "assume that we still live in the old world where 'you want to compute X? spawn a process, work in-core and compute and spew out your result, then exit(3) will clean up after you' was the norm. And our codebase has an easy way to tell the object API to allocate N extra bytes for app specific per object bookkeeping purpose. Now, would you use that facility to store your data there because you'd need that data for all objects you touch in your application?" and if the answer is yes, it belongs to slab, otherwise you are better off with a separate hashtable indexed via object names populated only for few selected objects you care about. For example, the slab is something I would have used to rewrite "show-branch", since it would have been really handy to have more bits in per-object "flags", and the most natural way to write that application is to keep one bit in all objects it slurps in core for every starting ref. > This particular case may not be representative, either. I picked it > because it was easy to convert. But I wonder how bad it would be to put > the object flags for a traversal into a hash. Right now those are in the > original struct, not even in a commit-slab. So I'd guess it's an even > bigger slowdown. True, too.