Thread (1 message) 1 message, 1 author, 2016-06-15

Re: [PATCH 3/3] commit-slab: introduce a macro to define a slab for new type

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:56:49

Jeff King [off-list ref] writes:
On Sat, Apr 13, 2013 at 11:04:49PM -0700, Junio C Hamano wrote:
quoted
Suppose you want to give one bit per existing ref and paint commits
down to find which refs are descendants of each commit. You find
that you have 320 refs only at runtime.

The code can declare a commit slab "struct flagbits"

	define_commit_slab(flagbits, unsigned char);
	struct flagbits flags;

and initialize it by:

	nrefs = ... count number of refs that returns say 320 ...
	init_flagbits_with_stride(&flags, (nrefs + 7) / 8);

so that

	unsigned char *fp = flagbits_at(&flags, commit);

will return a pointer pointing at an array of 40 "unsigned char"s
associated with the commit.
Thanks, I was thinking originally that we would want to break it down
into "unsigned long" or something, but there is probably no real
performance advantage to doing that over bytes.
The 320 came from writing "an array of 5 unsigned long long" in the
first draft ;-)
I'd probably further wrap it with a flagbit_set and flagbit_tst to wrap
the "figure out which byte, then which bit of that byte" logic, but that
would be a wrapper around flagbits_at, anyway. It can come later.
Exactly. At that point, it is not about "what you could use commit
slab for" but is about "how you would implement unbounded set of
flag bits".
We'd probably want the hot path of this (returning the actual pointer)
to be inline, but not necessarily the parts about growing,...
Yeah, this was just a technology demonstration as your original.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help