summaryrefslogtreecommitdiff
path: root/pack-bitmap.c
diff options
context:
space:
mode:
authorJeff King <peff@peff.net>2020-12-08 22:04:34 (GMT)
committerJunio C Hamano <gitster@pobox.com>2020-12-08 22:48:17 (GMT)
commit449fa5ee06906ca6d109e06b14cb4f8ea60a6c88 (patch)
tree0c8635baf66e570791698635e6f7bcf6e46ca677 /pack-bitmap.c
parent089f751360f62545a8fa836ad8132eb1260d2723 (diff)
downloadgit-449fa5ee06906ca6d109e06b14cb4f8ea60a6c88.zip
git-449fa5ee06906ca6d109e06b14cb4f8ea60a6c88.tar.gz
git-449fa5ee06906ca6d109e06b14cb4f8ea60a6c88.tar.bz2
pack-bitmap-write: ignore BITMAP_FLAG_REUSE
The on-disk bitmap format has a flag to mark a bitmap to be "reused". This is a rather curious feature, and works like this: - a run of pack-objects would decide to mark the last 80% of the bitmaps it generates with the reuse flag - the next time we generate bitmaps, we'd see those reuse flags from the last run, and mark those commits as special: - we'd be more likely to select those commits to get bitmaps in the new output - when generating the bitmap for a selected commit, we'd reuse the old bitmap as-is (rearranging the bits to match the new pack, of course) However, neither of these behaviors particularly makes sense. Just because a commit happened to be bitmapped last time does not make it a good candidate for having a bitmap this time. In particular, we may choose bitmaps based on how recent they are in history, or whether a ref tip points to them, and those things will change. We're better off re-considering fresh which commits are good candidates. Reusing the existing bitmap _is_ a reasonable thing to do to save computation. But only reusing exact bitmaps is a weak form of this. If we have an old bitmap for A and now want a new bitmap for its child, we should be able to compute that only by looking at trees and that are new to the child. But this code would consider only exact reuse (which is perhaps why it was eager to select those commits in the first place). Furthermore, the recent switch to the reverse-edge algorithm for generating bitmaps dropped this optimization entirely (and yet still performs better). So let's do a few cleanups: - drop the whole "reusing bitmaps" phase of generating bitmaps. It's not helping anything, and is mostly unused code (or worse, code that is using CPU but not doing anything useful) - drop the use of the on-disk reuse flag to select commits to bitmap - stop setting the on-disk reuse flag in bitmaps we generate (since nothing respects it anymore) We will keep a few innards of the reuse code, which will help us implement a more capable version of the "reuse" optimization: - simplify rebuild_existing_bitmaps() into a function that only builds the mapping of bits between the old and new orders, but doesn't actually convert any bitmaps - make rebuild_bitmap() public; we'll call it lazily to convert bitmaps as we traverse (using the mapping created above) Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'pack-bitmap.c')
-rw-r--r--pack-bitmap.c46
1 files changed, 6 insertions, 40 deletions
diff --git a/pack-bitmap.c b/pack-bitmap.c
index 60c781d..d1368b6 100644
--- a/pack-bitmap.c
+++ b/pack-bitmap.c
@@ -1338,9 +1338,9 @@ void test_bitmap_walk(struct rev_info *revs)
free_bitmap_index(bitmap_git);
}
-static int rebuild_bitmap(uint32_t *reposition,
- struct ewah_bitmap *source,
- struct bitmap *dest)
+int rebuild_bitmap(const uint32_t *reposition,
+ struct ewah_bitmap *source,
+ struct bitmap *dest)
{
uint32_t pos = 0;
struct ewah_iterator it;
@@ -1369,19 +1369,11 @@ static int rebuild_bitmap(uint32_t *reposition,
return 0;
}
-int rebuild_existing_bitmaps(struct bitmap_index *bitmap_git,
- struct packing_data *mapping,
- kh_oid_map_t *reused_bitmaps,
- int show_progress)
+uint32_t *create_bitmap_mapping(struct bitmap_index *bitmap_git,
+ struct packing_data *mapping)
{
uint32_t i, num_objects;
uint32_t *reposition;
- struct bitmap *rebuild;
- struct stored_bitmap *stored;
- struct progress *progress = NULL;
-
- khiter_t hash_pos;
- int hash_ret;
num_objects = bitmap_git->pack->num_objects;
reposition = xcalloc(num_objects, sizeof(uint32_t));
@@ -1399,33 +1391,7 @@ int rebuild_existing_bitmaps(struct bitmap_index *bitmap_git,
reposition[i] = oe_in_pack_pos(mapping, oe) + 1;
}
- rebuild = bitmap_new();
- i = 0;
-
- if (show_progress)
- progress = start_progress("Reusing bitmaps", 0);
-
- kh_foreach_value(bitmap_git->bitmaps, stored, {
- if (stored->flags & BITMAP_FLAG_REUSE) {
- if (!rebuild_bitmap(reposition,
- lookup_stored_bitmap(stored),
- rebuild)) {
- hash_pos = kh_put_oid_map(reused_bitmaps,
- stored->oid,
- &hash_ret);
- kh_value(reused_bitmaps, hash_pos) =
- bitmap_to_ewah(rebuild);
- }
- bitmap_reset(rebuild);
- display_progress(progress, ++i);
- }
- });
-
- stop_progress(&progress);
-
- free(reposition);
- bitmap_free(rebuild);
- return 0;
+ return reposition;
}
void free_bitmap_index(struct bitmap_index *b)