> From: Derrick Stolee <dstolee@xxxxxxxxxxxxx>
>
> When constructing new bitmaps, we perform a commit and tree walk in
> fill_bitmap_commit() and fill_bitmap_tree(). This walk would benefit
> from using existing bitmaps when available. We must track the existing
> bitmaps and translate them into the new object order, but this is
> generally faster than parsing trees.
Makes sense.
> In fill_bitmap_commit(), we must reorder thing somewhat. The priority
> queue walks commits from newest-to-oldest, which means we correctly stop
> walking when reaching a commit with a bitmap.
Makes sense.
> However, if we walk trees
> from top to bottom, then we might be parsing trees that are actually
> part of a re-used bitmap.
Isn't the issue that we shouldn't walk trees at all before exhausting
our commit search, not the direction that we walk the trees in (top to
bottom or bottom to top or whatever)?
> To avoid over-walking trees, add them to a
> LIFO queue and walk them from bottom-to-top after exploring commits
> completely.
Just to clarify - would it work just as well with a FIFO queue (not LIFO
queue)? It seems to me that the most important part is doing this after
exploring commits completely.
> On git.git, this reduces a second immediate bitmap computation from 2.0s
> to 1.0s. On linux.git, we go from 32s to 22s. On chromium's fork
> network, we go from 227s to 198s.
Nice timings.
> static void fill_bitmap_commit(struct bb_commit *ent,
> struct commit *commit,
> - struct prio_queue *queue)
> + struct prio_queue *queue,
> + struct prio_queue *tree_queue,
> + struct bitmap_index *old_bitmap,
> + const uint32_t *mapping)
> {
> if (!ent->bitmap)
> ent->bitmap = bitmap_new();
>
> - bitmap_set(ent->bitmap, find_object_pos(&commit->object.oid));
> prio_queue_put(queue, commit);
>
> while (queue->nr) {
> struct commit_list *p;
> struct commit *c = prio_queue_get(queue);
>
> + /*
> + * If this commit has an old bitmap, then translate that
> + * bitmap and add its bits to this one. No need to walk
> + * parents or the tree for this commit.
> + */
This comment should be right before "if (old && ...", I think. Here, it
is a bit misleading. It leads me to think that "this commit has an old
bitmap" means old_bitmap != NULL, but it is actually old != NULL.
> + if (old_bitmap && mapping) {
This is defensive in that if we somehow calculate old_bitmap without
mapping (or the other way around) (which is a bug), things just slow
down instead of breaking. I'm OK with this, but I still wanted to call
it out.
> + struct ewah_bitmap *old;
> +
> + old = bitmap_for_commit(old_bitmap, c);
> + if (old && !rebuild_bitmap(mapping, old, ent->bitmap))
> + continue;
> + }
> +
> + /*
> + * Mark ourselves and queue our tree. The commit
> + * walk ensures we cover all parents.
> + */
> bitmap_set(ent->bitmap, find_object_pos(&c->object.oid));
> - fill_bitmap_tree(ent->bitmap, get_commit_tree(c));
> + prio_queue_put(tree_queue, get_commit_tree(c));
>
> for (p = c->parents; p; p = p->next) {
> int pos = find_object_pos(&p->item->object.oid);
[snip]
> @@ -386,6 +408,9 @@ void bitmap_writer_build(struct packing_data *to_pack)
> size_t i;
> int nr_stored = 0; /* for progress */
> struct prio_queue queue = { compare_commits_by_gen_then_commit_date };
> + struct prio_queue tree_queue = { NULL };
NULL here does mean LIFO queue. OK.
> @@ -395,6 +420,12 @@ void bitmap_writer_build(struct packing_data *to_pack)
> trace2_region_enter("pack-bitmap-write", "building_bitmaps_total",
> the_repository);
>
> + old_bitmap = prepare_bitmap_git(to_pack->repo);
> + if (old_bitmap)
> + mapping = create_bitmap_mapping(old_bitmap, to_pack);
> + else
> + mapping = NULL;
Here, we prepare the old_bitmap and mapping arguments. OK.
