On Tue, Nov 19, 2024 at 06:08:24PM -0500, Taylor Blau wrote:
> Then when running the same command, we get results that are quite
> encouraging. The runtime jumps to 24.213 seconds, which is ~9.73 seconds
> slower than the average of the baseline measurements. But it takes
> ~10.418 seconds on my machine to compute the forward index. So it's
> really around 688ms *faster* than the baseline, despite doing a little
> more work.
Sorry, there is a much quicker way to generate the forward index at
runtime, which is the following:
--- 8< ---
diff --git a/midx.c b/midx.c
index 67e0d64004..1023bfa51a 100644
--- a/midx.c
+++ b/midx.c
@@ -989,3 +989,17 @@ int verify_midx_file(struct repository *r, const char *object_dir, unsigned flag
return verify_midx_error;
}
+
+void midx_populate_forward_index(struct multi_pack_index *m)
+{
+ uint32_t i;
+
+ ALLOC_ARRAY(m->forward_idx, m->num_objects);
+
+ trace2_region_enter("midx", "populate_forward_index", the_repository);
+
+ for (i = 0; i < m->num_objects; i++)
+ m->forward_idx[pack_pos_to_midx(m, i)] = i;
+
+ trace2_region_leave("midx", "populate_forward_index", the_repository);
+}
--- >8 ---
I don't know if this makes as much of a difference for regular
multi-pack reuse, since there we're only making calls to
midx_pair_to_pack_pos(), which already uses midx_pack_order_cmp(), so
there isn't any additional translation to do.
Thanks,
Taylor
