Am 29.06.21 um 22:53 schrieb Eric Wong: > This saves 8K per `struct object_directory', meaning it saves > around 800MB in my case involving 100K alternates (half or more > of those alternates are unlikely to hold loose objects). > > This is implemented in two parts: a generic, allocation-free > `cbtree' and the `oidtree' wrapper on top of it. The latter > provides allocation using alloc_state as a memory pool to > improve locality and reduce free(3) overhead. > > Unlike oid-array, the crit-bit tree does not require sorting. > Performance is bound by the key length, for oidtree that is > fixed at sizeof(struct object_id). There's no need to have > 256 oidtrees to mitigate the O(n log n) overhead like we did > with oid-array. > > Being a prefix trie, it is natively suited for expanding short > object IDs via prefix-limited iteration in > `find_short_object_filename'. Sounds like a good match. > > On my busy workstation, p4205 performance seems to be roughly > unchanged (+/-8%). Startup with 100K total alternates with no > loose objects seems around 10-20% faster on a hot cache. > (800MB in memory savings means more memory for the kernel FS > cache). > > The generic cbtree implementation does impose some extra > overhead for oidtree in that it uses memcmp(3) on > "struct object_id" so it wastes cycles comparing 12 extra bytes > on SHA-1 repositories. I've not yet explored reducing this > overhead, but I expect there are many places in our code base > where we'd want to investigate this. > > More information on crit-bit trees: https://cr.yp.to/critbit.html > > v2: make oidtree test hash-agnostic > > Signed-off-by: Eric Wong <e@xxxxxxxxx> > --- > Makefile | 3 + > alloc.c | 6 ++ > alloc.h | 1 + > cbtree.c | 167 ++++++++++++++++++++++++++++++++++++++++ > cbtree.h | 56 ++++++++++++++ > object-file.c | 17 ++-- > object-name.c | 28 +++---- > object-store.h | 5 +- > oidtree.c | 94 ++++++++++++++++++++++ > oidtree.h | 29 +++++++ > t/helper/test-oidtree.c | 47 +++++++++++ > t/helper/test-tool.c | 1 + > t/helper/test-tool.h | 1 + > t/t0069-oidtree.sh | 52 +++++++++++++ > 14 files changed, 478 insertions(+), 29 deletions(-) > create mode 100644 cbtree.c > create mode 100644 cbtree.h > create mode 100644 oidtree.c > create mode 100644 oidtree.h > create mode 100644 t/helper/test-oidtree.c > create mode 100755 t/t0069-oidtree.sh > > diff --git a/Makefile b/Makefile > index c3565fc0f8..a1525978fb 100644 > --- a/Makefile > +++ b/Makefile > @@ -722,6 +722,7 @@ TEST_BUILTINS_OBJS += test-mergesort.o > TEST_BUILTINS_OBJS += test-mktemp.o > TEST_BUILTINS_OBJS += test-oid-array.o > TEST_BUILTINS_OBJS += test-oidmap.o > +TEST_BUILTINS_OBJS += test-oidtree.o > TEST_BUILTINS_OBJS += test-online-cpus.o > TEST_BUILTINS_OBJS += test-parse-options.o > TEST_BUILTINS_OBJS += test-parse-pathspec-file.o > @@ -845,6 +846,7 @@ LIB_OBJS += branch.o > LIB_OBJS += bulk-checkin.o > LIB_OBJS += bundle.o > LIB_OBJS += cache-tree.o > +LIB_OBJS += cbtree.o > LIB_OBJS += chdir-notify.o > LIB_OBJS += checkout.o > LIB_OBJS += chunk-format.o > @@ -940,6 +942,7 @@ LIB_OBJS += object.o > LIB_OBJS += oid-array.o > LIB_OBJS += oidmap.o > LIB_OBJS += oidset.o > +LIB_OBJS += oidtree.o > LIB_OBJS += pack-bitmap-write.o > LIB_OBJS += pack-bitmap.o > LIB_OBJS += pack-check.o > diff --git a/alloc.c b/alloc.c > index 957a0af362..ca1e178c5a 100644 > --- a/alloc.c > +++ b/alloc.c > @@ -14,6 +14,7 @@ > #include "tree.h" > #include "commit.h" > #include "tag.h" > +#include "oidtree.h" > #include "alloc.h" > > #define BLOCKING 1024 > @@ -123,6 +124,11 @@ void *alloc_commit_node(struct repository *r) > return c; > } > > +void *alloc_from_state(struct alloc_state *alloc_state, size_t n) > +{ > + return alloc_node(alloc_state, n); > +} > + Why extend alloc.c instead of using mem-pool.c? (I don't know which fits better, but when you say "memory pool" and not use mem-pool.c I just have to ask..) > diff --git a/oidtree.c b/oidtree.c > new file mode 100644 > index 0000000000..c1188d8f48 > --- /dev/null > +++ b/oidtree.c > @@ -0,0 +1,94 @@ > +/* > + * A wrapper around cbtree which stores oids > + * May be used to replace oid-array for prefix (abbreviation) matches > + */ > +#include "oidtree.h" > +#include "alloc.h" > +#include "hash.h" > + > +struct oidtree_node { > + /* n.k[] is used to store "struct object_id" */ > + struct cb_node n; > +}; > + > +struct oidtree_iter_data { > + oidtree_iter fn; > + void *arg; > + size_t *last_nibble_at; > + int algo; > + uint8_t last_byte; > +}; > + > +void oidtree_destroy(struct oidtree *ot) > +{ > + if (ot->mempool) { > + clear_alloc_state(ot->mempool); > + FREE_AND_NULL(ot->mempool); > + } > + oidtree_init(ot); > +} > + > +void oidtree_insert(struct oidtree *ot, const struct object_id *oid) > +{ > + struct oidtree_node *on; > + > + if (!ot->mempool) > + ot->mempool = allocate_alloc_state(); > + if (!oid->algo) > + BUG("oidtree_insert requires oid->algo"); > + > + on = alloc_from_state(ot->mempool, sizeof(*on) + sizeof(*oid)); > + oidcpy_with_padding((struct object_id *)on->n.k, oid); > + > + /* > + * n.b. we shouldn't get duplicates, here, but we'll have > + * a small leak that won't be freed until oidtree_destroy > + */ Why shouldn't we get duplicates? That depends on the usage of oidtree, right? The current user is fine because we avoid reading the same loose object directory twice using the loose_objects_subdir_seen bitmap. The leak comes from the allocation above, which is not used in case we already have the key in the oidtree. So we need memory for all candidates, not just the inserted candidates. That's probably acceptable in most use cases. We can do better by keeping track of the unnecessary allocation in struct oidtree and recycling it at the next insert attempt, however. That way we'd only waste at most one slot. > + cb_insert(&ot->t, &on->n, sizeof(*oid)); > +} > + > +int oidtree_contains(struct oidtree *ot, const struct object_id *oid) > +{ > + struct object_id k = { 0 }; > + size_t klen = sizeof(k); > + oidcpy_with_padding(&k, oid); Why initialize k; isn't oidcpy_with_padding() supposed to overwrite it completely? > + > + if (oid->algo == GIT_HASH_UNKNOWN) { > + k.algo = hash_algo_by_ptr(the_hash_algo); > + klen -= sizeof(oid->algo); > + } This relies on the order of the members hash and algo in struct object_id to find a matching hash if we don't actually know algo. It also relies on the absence of padding after algo. Would something like this make sense? BUILD_ASSERT_OR_ZERO(offsetof(struct object_id, algo) + sizeof(k.algo) == sizeof(k)); And why set k.algo to some arbitrary value if we ignore it anyway? I.e. why not keep it GIT_HASH_UNKNOWN, as set by oidcpy_with_padding()? > + > + return cb_lookup(&ot->t, (const uint8_t *)&k, klen) ? 1 : 0; > +} > + > +static enum cb_next iter(struct cb_node *n, void *arg) > +{ > + struct oidtree_iter_data *x = arg; > + const struct object_id *oid = (const struct object_id *)n->k; > + > + if (x->algo != GIT_HASH_UNKNOWN && x->algo != oid->algo) > + return CB_CONTINUE; > + > + if (x->last_nibble_at) { > + if ((oid->hash[*x->last_nibble_at] ^ x->last_byte) & 0xf0) > + return CB_CONTINUE; > + } > + > + return x->fn(oid, x->arg); > +} > + > +void oidtree_each(struct oidtree *ot, const struct object_id *oid, > + size_t oidhexlen, oidtree_iter fn, void *arg) > +{ > + size_t klen = oidhexlen / 2; > + struct oidtree_iter_data x = { 0 }; > + > + x.fn = fn; > + x.arg = arg; > + x.algo = oid->algo; > + if (oidhexlen & 1) { > + x.last_byte = oid->hash[klen]; > + x.last_nibble_at = &klen; > + } > + cb_each(&ot->t, (const uint8_t *)oid, klen, iter, &x); > +} Clamp oidhexlen at GIT_MAX_HEXSZ? Or die? René
