Re: [PATCH] describe: use khash in finish_depth_computation()

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> 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.