On Mon, Mar 18 2019, Jeff Hostetler via GitGitGadget wrote:
> +static int compare_pair_pos_vs_id(const void *_a, const void *_b)
> +{
> + struct pair_pos_vs_id *a = (struct pair_pos_vs_id *)_a;
> + struct pair_pos_vs_id *b = (struct pair_pos_vs_id *)_b;
> +
> + if (a->pack_int_id < b->pack_int_id)
> + return -1;
> + if (a->pack_int_id > b->pack_int_id)
> + return 1;
> +
> + return 0;
> +}
Not a suggestion for a change, just a note that this sent me down the
rabbit hole of looking at the different idioms we use for QSORT() in
different places. Some use this form, some a ternary nest, and some the
succinct subtraction idiom of e.g. (in this case):
return b->pack_int_id - a->pack_int_id;
> +
> int verify_midx_file(const char *object_dir)
> {
> - uint32_t i;
> + struct pair_pos_vs_id *pairs = NULL;
> + uint32_t i, k;
> struct progress *progress;
> struct multi_pack_index *m = load_multi_pack_index(object_dir, 1);
> verify_midx_error = 0;
> @@ -997,15 +1017,36 @@ int verify_midx_file(const char *object_dir)
> }
>
> progress = start_progress(_("Verifying object offsets"), m->num_objects);
> +
> + /*
> + * Create an array mapping each object to its packfile id. Sort it
> + * to group the objects by packfile. Use this permutation to visit
> + * each of the objects and only require 1 packfile to be open at a
> + * time.
> + */
> + ALLOC_ARRAY(pairs, m->num_objects);
> for (i = 0; i < m->num_objects; i++) {
> + pairs[i].pos = i;
> + pairs[i].pack_int_id = nth_midxed_pack_int_id(m, i);
> + }
> + QSORT(pairs, m->num_objects, compare_pair_pos_vs_id);
> +
> + for (k = 0; k < m->num_objects; k++) {
> [...]
I have not tested this (or midx in general), but isn't this new QSORT()
introducing the same sort of progress stalling that I fixed for
commit-graph in 890226ccb57 ("commit-graph write: add itermediate
progress", 2019-01-19)? I.e. something you can work around with a
"display_progress(progress, 0)" before the QSORT().
