tree bfa04e7c794926c8969270a8c2f37fb2300a6099
parent 5c1c006307cac302b07d42ed3172a3cb3e630dcc
author Antonio Barone <syntonyze@gmail.com> 1713887482 +0200
committer Antonio Barone <syntonyze@gmail.com> 1713888960 +0200

Introduce `quickMatchSearchForReuse` config.

During the search for reuse phase jgit attempts to find the best object
representation by scanning all existing packfiles.

This ensures that the best delta representation is selected from all the
available ones, effectively saving space when repacking objects in
packfiles.

In a scenario where the number of packfiles is large however (i.e.
thousands of packfiles), this thorough search to find the best object
representation could be quite time consuming, up to the point where it
becomes unacceptable, leading to a "Search for reuse phase" to last
several minutes.

Introduce the possibility to trade-off between efficiency and the
quality of object representation chosen during the search for reuse
phase, by introducing the `quickMatchSearchForReuse` config.

When enabled, the search stops scanning upon finding the first matching
object representation, potentially sacrificing finding the best
representation for efficiency.

To increase the chance to find the best (or at least a very good) object
representation, when `quickMatchSearchForReuse` is enabled, the
packfiles are scanned from the most recent to the oldest, giving
priority to the ones having a bitmap, so that the most recent repacks
are traversed first.

We tested this on a ~3Gb repository having ~4M objects spanning across
4k packfiles on a Mac M3 with 36 GB ram: The search for reuse phase
during a GC operation goes down from ~3 minutes to ~20 seconds.

Change-Id: Ib44efded20c2e09a44b6234412a2cf94e7cd4b0f