Commit fde67d68 authored by Jeff King's avatar Jeff King Committed by Junio C Hamano

prune: use bitmaps for reachability traversal

Pruning generally has to traverse the whole commit graph in order to
see which objects are reachable. This is the exact problem that
reachability bitmaps were meant to solve, so let's use them (if they're
available, of course).

Here are timings on git.git:

  Test                            HEAD^             HEAD
  5304.6: prune with bitmaps      3.65(3.56+0.09)   1.01(0.92+0.08) -72.3%

And on linux.git:

  Test                            HEAD^               HEAD
  5304.6: prune with bitmaps      35.05(34.79+0.23)   3.00(2.78+0.21) -91.4%

The tests show a pretty optimal case, as we'll have just repacked and
should have pretty good coverage of all refs with our bitmaps. But
that's actually pretty realistic: normally prune is run via "gc" right
after repacking.

A few notes on the implementation:

  - the change is actually in reachable.c, so it would improve
    reachability traversals by "reflog expire --stale-fix", as well.
    Those aren't performed regularly, though (a normal "git gc" doesn't
    use --stale-fix), so they're not really worth measuring. There's a
    low chance of regressing that caller, since the use of bitmaps is
    totally transparent from the caller's perspective.

  - The bitmap case could actually get away without creating a "struct
    object", and instead the caller could just look up each object id in
    the bitmap result. However, this would be a marginal improvement in
    runtime, and it would make the callers much more complicated. They'd
    have to handle both the bitmap and non-bitmap cases separately, and
    in the case of git-prune, we'd also have to tweak prune_shallow(),
    which relies on our SEEN flags.

  - Because we do create real object structs, we go through a few
    contortions to create ones of the right type. This isn't strictly
    necessary (lookup_unknown_object() would suffice), but it's more
    memory efficient to use the correct types, since we already know
Signed-off-by: 's avatarJeff King <>
Signed-off-by: 's avatarJunio C Hamano <>
parent d55a30bb
......@@ -12,6 +12,7 @@
#include "packfile.h"
#include "worktree.h"
#include "object-store.h"
#include "pack-bitmap.h"
struct connectivity_progress {
struct progress *progress;
......@@ -158,10 +159,44 @@ int add_unseen_recent_objects_to_traversal(struct rev_info *revs,
static void *lookup_object_by_type(struct repository *r,
const struct object_id *oid,
enum object_type type)
switch (type) {
return lookup_commit(r, oid);
case OBJ_TREE:
return lookup_tree(r, oid);
case OBJ_TAG:
return lookup_tag(r, oid);
case OBJ_BLOB:
return lookup_blob(r, oid);
die("BUG: unknown object type %d", type);
static int mark_object_seen(const struct object_id *oid,
enum object_type type,
int exclude,
uint32_t name_hash,
struct packed_git *found_pack,
off_t found_offset)
struct object *obj = lookup_object_by_type(the_repository, oid, type);
if (!obj)
die("unable to create object '%s'", oid_to_hex(oid));
obj->flags |= SEEN;
return 0;
void mark_reachable_objects(struct rev_info *revs, int mark_reflog,
timestamp_t mark_recent, struct progress *progress)
struct connectivity_progress cp;
struct bitmap_index *bitmap_git;
* Set up revision parsing, and mark us as being interested
......@@ -188,6 +223,13 @@ void mark_reachable_objects(struct rev_info *revs, int mark_reflog,
cp.progress = progress;
cp.count = 0;
bitmap_git = prepare_bitmap_walk(revs);
if (bitmap_git) {
traverse_bitmap_commit_list(bitmap_git, mark_object_seen);
* Set up the revision walk - this will move all commits
* from the pending list to the commit walking list.
......@@ -21,4 +21,15 @@ test_perf 'prune with no objects' '
git prune
test_expect_success 'repack with bitmaps' '
git repack -adb
# We have to create the object in each trial run, since otherwise
# runs after the first see no object and just skip the traversal entirely!
test_perf 'prune with bitmaps' '
echo "probably not present in repo" | git hash-object -w --stdin &&
git prune
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment