2018-10-27 08:23:22 +02:00
|
|
|
pack.window::
|
|
|
|
The size of the window used by linkgit:git-pack-objects[1] when no
|
|
|
|
window size is given on the command line. Defaults to 10.
|
|
|
|
|
|
|
|
pack.depth::
|
|
|
|
The maximum delta depth used by linkgit:git-pack-objects[1] when no
|
|
|
|
maximum depth is given on the command line. Defaults to 50.
|
|
|
|
Maximum value is 4095.
|
|
|
|
|
|
|
|
pack.windowMemory::
|
|
|
|
The maximum size of memory that is consumed by each thread
|
|
|
|
in linkgit:git-pack-objects[1] for pack window memory when
|
|
|
|
no limit is given on the command line. The value can be
|
|
|
|
suffixed with "k", "m", or "g". When left unconfigured (or
|
|
|
|
set explicitly to 0), there will be no limit.
|
|
|
|
|
|
|
|
pack.compression::
|
|
|
|
An integer -1..9, indicating the compression level for objects
|
|
|
|
in a pack file. -1 is the zlib default. 0 means no
|
|
|
|
compression, and 1..9 are various speed/size tradeoffs, 9 being
|
|
|
|
slowest. If not set, defaults to core.compression. If that is
|
|
|
|
not set, defaults to -1, the zlib default, which is "a default
|
|
|
|
compromise between speed and compression (currently equivalent
|
|
|
|
to level 6)."
|
|
|
|
+
|
|
|
|
Note that changing the compression level will not automatically recompress
|
|
|
|
all existing objects. You can force recompression by passing the -F option
|
|
|
|
to linkgit:git-repack[1].
|
|
|
|
|
2019-12-18 12:25:43 +01:00
|
|
|
pack.allowPackReuse::
|
|
|
|
When true, and when reachability bitmaps are enabled,
|
|
|
|
pack-objects will try to send parts of the bitmapped packfile
|
|
|
|
verbatim. This can reduce memory and CPU usage to serve fetches,
|
|
|
|
but might result in sending a slightly larger pack. Defaults to
|
|
|
|
true.
|
|
|
|
|
2018-10-27 08:23:22 +02:00
|
|
|
pack.island::
|
|
|
|
An extended regular expression configuring a set of delta
|
|
|
|
islands. See "DELTA ISLANDS" in linkgit:git-pack-objects[1]
|
|
|
|
for details.
|
|
|
|
|
|
|
|
pack.islandCore::
|
|
|
|
Specify an island name which gets to have its objects be
|
|
|
|
packed first. This creates a kind of pseudo-pack at the front
|
|
|
|
of one pack, so that the objects from the specified island are
|
|
|
|
hopefully faster to copy into any pack that should be served
|
|
|
|
to a user requesting these objects. In practice this means
|
|
|
|
that the island specified should likely correspond to what is
|
|
|
|
the most commonly cloned in the repo. See also "DELTA ISLANDS"
|
|
|
|
in linkgit:git-pack-objects[1].
|
|
|
|
|
|
|
|
pack.deltaCacheSize::
|
|
|
|
The maximum memory in bytes used for caching deltas in
|
|
|
|
linkgit:git-pack-objects[1] before writing them out to a pack.
|
|
|
|
This cache is used to speed up the writing object phase by not
|
|
|
|
having to recompute the final delta result once the best match
|
|
|
|
for all objects is found. Repacking large repositories on machines
|
|
|
|
which are tight with memory might be badly impacted by this though,
|
|
|
|
especially if this cache pushes the system into swapping.
|
|
|
|
A value of 0 means no limit. The smallest size of 1 byte may be
|
|
|
|
used to virtually disable this cache. Defaults to 256 MiB.
|
|
|
|
|
|
|
|
pack.deltaCacheLimit::
|
|
|
|
The maximum size of a delta, that is cached in
|
|
|
|
linkgit:git-pack-objects[1]. This cache is used to speed up the
|
|
|
|
writing object phase by not having to recompute the final delta
|
|
|
|
result once the best match for all objects is found.
|
|
|
|
Defaults to 1000. Maximum value is 65535.
|
|
|
|
|
|
|
|
pack.threads::
|
|
|
|
Specifies the number of threads to spawn when searching for best
|
|
|
|
delta matches. This requires that linkgit:git-pack-objects[1]
|
|
|
|
be compiled with pthreads otherwise this option is ignored with a
|
|
|
|
warning. This is meant to reduce packing time on multiprocessor
|
|
|
|
machines. The required amount of memory for the delta search window
|
|
|
|
is however multiplied by the number of threads.
|
|
|
|
Specifying 0 will cause Git to auto-detect the number of CPU's
|
|
|
|
and set the number of threads accordingly.
|
|
|
|
|
|
|
|
pack.indexVersion::
|
|
|
|
Specify the default pack index version. Valid values are 1 for
|
|
|
|
legacy pack index used by Git versions prior to 1.5.2, and 2 for
|
|
|
|
the new pack index with capabilities for packs larger than 4 GB
|
|
|
|
as well as proper protection against the repacking of corrupted
|
|
|
|
packs. Version 2 is the default. Note that version 2 is enforced
|
|
|
|
and this config option ignored whenever the corresponding pack is
|
|
|
|
larger than 2 GB.
|
|
|
|
+
|
|
|
|
If you have an old Git that does not understand the version 2 `*.idx` file,
|
|
|
|
cloning or fetching over a non native protocol (e.g. "http")
|
|
|
|
that will copy both `*.pack` file and corresponding `*.idx` file from the
|
|
|
|
other side may give you a repository that cannot be accessed with your
|
|
|
|
older version of Git. If the `*.pack` file is smaller than 2 GB, however,
|
|
|
|
you can use linkgit:git-index-pack[1] on the *.pack file to regenerate
|
|
|
|
the `*.idx` file.
|
|
|
|
|
|
|
|
pack.packSizeLimit::
|
|
|
|
The maximum size of a pack. This setting only affects
|
|
|
|
packing to a file when repacking, i.e. the git:// protocol
|
|
|
|
is unaffected. It can be overridden by the `--max-pack-size`
|
|
|
|
option of linkgit:git-repack[1]. Reaching this limit results
|
2021-06-08 09:24:48 +02:00
|
|
|
in the creation of multiple packfiles.
|
|
|
|
+
|
|
|
|
Note that this option is rarely useful, and may result in a larger total
|
|
|
|
on-disk size (because Git will not store deltas between packs), as well
|
|
|
|
as worse runtime performance (object lookup within multiple packs is
|
|
|
|
slower than a single pack, and optimizations like reachability bitmaps
|
|
|
|
cannot cope with multiple packs).
|
|
|
|
+
|
|
|
|
If you need to actively run Git using smaller packfiles (e.g., because your
|
|
|
|
filesystem does not support large files), this option may help. But if
|
|
|
|
your goal is to transmit a packfile over a medium that supports limited
|
|
|
|
sizes (e.g., removable media that cannot store the whole repository),
|
|
|
|
you are likely better off creating a single large packfile and splitting
|
|
|
|
it using a generic multi-volume archive tool (e.g., Unix `split`).
|
|
|
|
+
|
|
|
|
The minimum size allowed is limited to 1 MiB. The default is unlimited.
|
|
|
|
Common unit suffixes of 'k', 'm', or 'g' are supported.
|
2018-10-27 08:23:22 +02:00
|
|
|
|
|
|
|
pack.useBitmaps::
|
|
|
|
When true, git will use pack bitmaps (if available) when packing
|
|
|
|
to stdout (e.g., during the server side of a fetch). Defaults to
|
|
|
|
true. You should not generally need to turn this off unless
|
|
|
|
you are debugging pack bitmaps.
|
|
|
|
|
2019-01-16 19:26:00 +01:00
|
|
|
pack.useSparse::
|
|
|
|
When true, git will default to using the '--sparse' option in
|
|
|
|
'git pack-objects' when the '--revs' option is present. This
|
|
|
|
algorithm only walks trees that appear in paths that introduce new
|
|
|
|
objects. This can have significant performance benefits when
|
|
|
|
computing a pack to send a small change. However, it is possible
|
|
|
|
that extra objects are added to the pack-file if the included
|
2020-03-20 13:38:09 +01:00
|
|
|
commits contain certain types of direct renames. Default is
|
|
|
|
`true`.
|
2019-01-16 19:26:00 +01:00
|
|
|
|
builtin/pack-objects.c: respect 'pack.preferBitmapTips'
When writing a new pack with a bitmap, it is sometimes convenient to
indicate some reference prefixes which should receive priority when
selecting which commits to receive bitmaps.
A truly motivated caller could accomplish this by setting
'pack.islandCore', (since all commits in the core island are similarly
marked as preferred) but this requires callers to opt into using delta
islands, which they may or may not want to do.
Introduce a new multi-valued configuration, 'pack.preferBitmapTips' to
allow callers to specify a list of reference prefixes. All references
which have a prefix contained in 'pack.preferBitmapTips' will mark their
tips as "preferred" in the same way as commits are marked as preferred
for selection by 'pack.islandCore'.
The choice of the verb "prefer" is intentional: marking the NEEDS_BITMAP
flag on an object does *not* guarantee that that object will receive a
bitmap. It merely guarantees that that commit will receive a bitmap over
any *other* commit in the same window by bitmap_writer_select_commits().
The test this patch adds reflects this quirk, too. It only tests that
a commit (which didn't receive bitmaps by default) is selected for
bitmaps after changing the value of 'pack.preferBitmapTips' to include
it. Other commits may lose their bitmaps as a byproduct of how the
selection process works (bitmap_writer_select_commits() ignores the
remainder of a window after seeing a commit with the NEEDS_BITMAP flag).
This configuration will aide in selecting important references for
multi-pack bitmaps, since they do not respect the same pack.islandCore
configuration. (They could, but doing so may be confusing, since it is
packs--not bitmaps--which are influenced by the delta-islands
configuration).
In a fork network repository (one which lists all forks of a given
repository as remotes), for example, it is useful to set
pack.preferBitmapTips to 'refs/remotes/<root>/heads' and
'refs/remotes/<root>/tags', where '<root>' is an opaque identifier
referring to the repository which is at the base of the fork chain.
Suggested-by: Jeff King <peff@peff.net>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-01 03:32:14 +02:00
|
|
|
pack.preferBitmapTips::
|
|
|
|
When selecting which commits will receive bitmaps, prefer a
|
|
|
|
commit at the tip of any reference that is a suffix of any value
|
|
|
|
of this configuration over any other commits in the "selection
|
|
|
|
window".
|
|
|
|
+
|
|
|
|
Note that setting this configuration to `refs/foo` does not mean that
|
|
|
|
the commits at the tips of `refs/foo/bar` and `refs/foo/baz` will
|
|
|
|
necessarily be selected. This is because commits are selected for
|
|
|
|
bitmaps from within a series of windows of variable length.
|
|
|
|
+
|
|
|
|
If a commit at the tip of any reference which is a suffix of any value
|
|
|
|
of this configuration is seen in a window, it is immediately given
|
|
|
|
preference over any other commit in that window.
|
|
|
|
|
2018-10-27 08:23:22 +02:00
|
|
|
pack.writeBitmaps (deprecated)::
|
|
|
|
This is a deprecated synonym for `repack.writeBitmaps`.
|
|
|
|
|
|
|
|
pack.writeBitmapHashCache::
|
|
|
|
When true, git will include a "hash cache" section in the bitmap
|
|
|
|
index (if one is written). This cache can be used to feed git's
|
|
|
|
delta heuristics, potentially leading to better deltas between
|
|
|
|
bitmapped and non-bitmapped objects (e.g., when serving a fetch
|
|
|
|
between an older, bitmapped pack and objects that have been
|
|
|
|
pushed since the last gc). The downside is that it consumes 4
|
pack-objects: default to writing bitmap hash-cache
Enabling pack.writebitmaphashcache should always be a performance win.
It costs only 4 bytes per object on disk, and the timings in ae4f07fbcc
(pack-bitmap: implement optional name_hash cache, 2013-12-21) show it
improving fetch and partial-bitmap clone times by 40-50%.
The only reason we didn't enable it by default at the time is that early
versions of JGit's bitmap reader complained about the presence of
optional header bits it didn't understand. But that was changed in
JGit's d2fa3987a (Use bitcheck to check for presence of OPT_FULL option,
2013-10-30), which made it into JGit v3.5.0 in late 2014.
So let's turn this option on by default. It's backwards-compatible with
all versions of Git, and if you are also using JGit on the same
repository, you'd only run into problems using a version that's almost 5
years old.
We'll drop the manual setting from all of our test scripts, including
perf tests. This isn't strictly necessary, but it has two advantages:
1. If the hash-cache ever stops being enabled by default, our perf
regression tests will notice.
2. We can use the modified perf tests to show off the behavior of an
otherwise unconfigured repo, as shown below.
These are the results of a few of a perf tests against linux.git that
showed interesting results. You can see the expected speedup in 5310.4,
which was noted in ae4f07fbcc. Curiously, 5310.8 did not improve (and
actually got slower), despite seeing the opposite in ae4f07fbcc.
I don't have an explanation for that.
The tests from p5311 did not exist back then, but do show improvements
(a smaller pack due to better deltas, which we found in less time).
Test HEAD^ HEAD
-------------------------------------------------------------------------------------
5310.4: simulated fetch 7.39(22.70+0.25) 5.64(11.43+0.22) -23.7%
5310.8: clone (partial bitmap) 18.45(24.83+1.19) 19.94(28.40+1.36) +8.1%
5311.31: server (128 days) 0.41(1.13+0.05) 0.34(0.72+0.02) -17.1%
5311.32: size (128 days) 7.4M 7.0M -4.8%
5311.33: client (128 days) 1.33(1.49+0.06) 1.29(1.37+0.12) -3.0%
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-15 07:25:28 +01:00
|
|
|
bytes per object of disk space. Defaults to true.
|
2021-09-15 00:06:06 +02:00
|
|
|
+
|
|
|
|
When writing a multi-pack reachability bitmap, no new namehashes are
|
|
|
|
computed; instead, any namehashes stored in an existing bitmap are
|
|
|
|
permuted into their appropriate location when writing a new bitmap.
|
2021-01-26 00:37:34 +01:00
|
|
|
|
2022-08-14 18:55:09 +02:00
|
|
|
pack.writeBitmapLookupTable::
|
|
|
|
When true, Git will include a "lookup table" section in the
|
|
|
|
bitmap index (if one is written). This table is used to defer
|
|
|
|
loading individual bitmaps as late as possible. This can be
|
|
|
|
beneficial in repositories that have relatively large bitmap
|
|
|
|
indexes. Defaults to false.
|
|
|
|
|
pack-revindex: introduce `pack.readReverseIndex`
Since 1615c567b8 (Documentation/config/pack.txt: advertise
'pack.writeReverseIndex', 2021-01-25), we have had the
`pack.writeReverseIndex` configuration option, which tells Git whether
or not it is allowed to write a ".rev" file when indexing a pack.
Introduce a complementary configuration knob, `pack.readReverseIndex` to
control whether or not Git will read any ".rev" file(s) that may be
available on disk.
This option is useful for debugging, as well as disabling the effect of
".rev" files in certain instances.
This is useful because of the trade-off[^1] between the time it takes to
generate a reverse index (slow from scratch, fast when reading an
existing ".rev" file), and the time it takes to access a record (the
opposite).
For example, even though it is faster to use the on-disk reverse index
when computing the on-disk size of a packed object, it is slower to
enumerate the same value for all objects.
Here are a couple of examples from linux.git. When computing the above
for a single object, using the on-disk reverse index is significantly
faster:
$ git rev-parse HEAD >in
$ hyperfine -L v false,true 'git.compile -c pack.readReverseIndex={v} cat-file --batch-check="%(objectsize:disk)" <in'
Benchmark 1: git.compile -c pack.readReverseIndex=false cat-file --batch-check="%(objectsize:disk)" <in
Time (mean ± σ): 302.5 ms ± 12.5 ms [User: 258.7 ms, System: 43.6 ms]
Range (min … max): 291.1 ms … 328.1 ms 10 runs
Benchmark 2: git.compile -c pack.readReverseIndex=true cat-file --batch-check="%(objectsize:disk)" <in
Time (mean ± σ): 3.9 ms ± 0.3 ms [User: 1.6 ms, System: 2.4 ms]
Range (min … max): 2.0 ms … 4.4 ms 801 runs
Summary
'git.compile -c pack.readReverseIndex=true cat-file --batch-check="%(objectsize:disk)" <in' ran
77.29 ± 7.14 times faster than 'git.compile -c pack.readReverseIndex=false cat-file --batch-check="%(objectsize:disk)" <in'
, but when instead trying to compute the on-disk object size for all
objects in the repository, using the ".rev" file is a disadvantage over
creating the reverse index from scratch:
$ hyperfine -L v false,true 'git.compile -c pack.readReverseIndex={v} cat-file --batch-check="%(objectsize:disk)" --batch-all-objects'
Benchmark 1: git.compile -c pack.readReverseIndex=false cat-file --batch-check="%(objectsize:disk)" --batch-all-objects
Time (mean ± σ): 8.258 s ± 0.035 s [User: 7.949 s, System: 0.308 s]
Range (min … max): 8.199 s … 8.293 s 10 runs
Benchmark 2: git.compile -c pack.readReverseIndex=true cat-file --batch-check="%(objectsize:disk)" --batch-all-objects
Time (mean ± σ): 16.976 s ± 0.107 s [User: 16.706 s, System: 0.268 s]
Range (min … max): 16.839 s … 17.105 s 10 runs
Summary
'git.compile -c pack.readReverseIndex=false cat-file --batch-check="%(objectsize:disk)" --batch-all-objects' ran
2.06 ± 0.02 times faster than 'git.compile -c pack.readReverseIndex=true cat-file --batch-check="%(objectsize:disk)" --batch-all-objects'
Luckily, the results when running `git cat-file` with `--unordered` are
closer together:
$ hyperfine -L v false,true 'git.compile -c pack.readReverseIndex={v} cat-file --unordered --batch-check="%(objectsize:disk)" --batch-all-objects'
Benchmark 1: git.compile -c pack.readReverseIndex=false cat-file --unordered --batch-check="%(objectsize:disk)" --batch-all-objects
Time (mean ± σ): 5.066 s ± 0.105 s [User: 4.792 s, System: 0.274 s]
Range (min … max): 4.943 s … 5.220 s 10 runs
Benchmark 2: git.compile -c pack.readReverseIndex=true cat-file --unordered --batch-check="%(objectsize:disk)" --batch-all-objects
Time (mean ± σ): 6.193 s ± 0.069 s [User: 5.937 s, System: 0.255 s]
Range (min … max): 6.145 s … 6.356 s 10 runs
Summary
'git.compile -c pack.readReverseIndex=false cat-file --unordered --batch-check="%(objectsize:disk)" --batch-all-objects' ran
1.22 ± 0.03 times faster than 'git.compile -c pack.readReverseIndex=true cat-file --unordered --batch-check="%(objectsize:disk)" --batch-all-objects'
Because the equilibrium point between these two is highly machine- and
repository-dependent, allow users to configure whether or not they will
read any ".rev" file(s) with this configuration knob.
[^1]: Generating a reverse index in memory takes O(N) time (where N is
the number of objects in the repository), since we use a radix sort.
Reading an entry from an on-disk ".rev" file is slower since each
operation is bound by disk I/O instead of memory I/O.
In order to compute the on-disk size of a packed object, we need to
find the offset of our object, and the adjacent object (the on-disk
size difference of these two). Finding the first offset requires a
binary search. Finding the latter involves a single .rev lookup.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Acked-by: Derrick Stolee <derrickstolee@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-04-13 00:20:30 +02:00
|
|
|
pack.readReverseIndex::
|
|
|
|
When true, git will read any .rev file(s) that may be available
|
|
|
|
(see: linkgit:gitformat-pack[5]). When false, the reverse index
|
|
|
|
will be generated from scratch and stored in memory. Defaults to
|
|
|
|
true.
|
|
|
|
|
2021-01-26 00:37:34 +01:00
|
|
|
pack.writeReverseIndex::
|
|
|
|
When true, git will write a corresponding .rev file (see:
|
2022-08-04 18:28:39 +02:00
|
|
|
linkgit:gitformat-pack[5])
|
2021-01-26 00:37:34 +01:00
|
|
|
for each new packfile that it writes in all places except for
|
|
|
|
linkgit:git-fast-import[1] and in the bulk checkin mechanism.
|
config: enable `pack.writeReverseIndex` by default
Back in e37d0b8730 (builtin/index-pack.c: write reverse indexes,
2021-01-25), Git learned how to read and write a pack's reverse index
from a file instead of in-memory.
A pack's reverse index is a mapping from pack position (that is, the
order that objects appear together in a ".pack") to their position in
lexical order (that is, the order that objects are listed in an ".idx"
file).
Reverse indexes are consulted often during pack-objects, as well as
during auxiliary operations that require mapping between pack offsets,
pack order, and index index.
They are useful in GitHub's infrastructure, where we have seen a
dramatic increase in performance when writing ".rev" files[1]. In
particular:
- an ~80% reduction in the time it takes to serve fetches on a popular
repository, Homebrew/homebrew-core.
- a ~60% reduction in the peak memory usage to serve fetches on that
same repository.
- a collective savings of ~35% in CPU time across all pack-objects
invocations serving fetches across all repositories in a single
datacenter.
Reverse indexes are also beneficial to end-users as well as forges. For
example, the time it takes to generate a pack containing the objects for
the 10 most recent commits in linux.git (representing a typical push) is
significantly faster when on-disk reverse indexes are available:
$ { git rev-parse HEAD && printf '^' && git rev-parse HEAD~10 } >in
$ hyperfine -L v false,true 'git.compile -c pack.readReverseIndex={v} pack-objects --delta-base-offset --revs --stdout <in >/dev/null'
Benchmark 1: git.compile -c pack.readReverseIndex=false pack-objects --delta-base-offset --revs --stdout <in >/dev/null
Time (mean ± σ): 543.0 ms ± 20.3 ms [User: 616.2 ms, System: 58.8 ms]
Range (min … max): 521.0 ms … 577.9 ms 10 runs
Benchmark 2: git.compile -c pack.readReverseIndex=true pack-objects --delta-base-offset --revs --stdout <in >/dev/null
Time (mean ± σ): 245.0 ms ± 11.4 ms [User: 335.6 ms, System: 31.3 ms]
Range (min … max): 226.0 ms … 259.6 ms 13 runs
Summary
'git.compile -c pack.readReverseIndex=true pack-objects --delta-base-offset --revs --stdout <in >/dev/null' ran
2.22 ± 0.13 times faster than 'git.compile -c pack.readReverseIndex=false pack-objects --delta-base-offset --revs --stdout <in >/dev/null'
The same is true of writing a pack containing the objects for the 30
most-recent commits:
$ { git rev-parse HEAD && printf '^' && git rev-parse HEAD~30 } >in
$ hyperfine -L v false,true 'git.compile -c pack.readReverseIndex={v} pack-objects --delta-base-offset --revs --stdout <in >/dev/null'
Benchmark 1: git.compile -c pack.readReverseIndex=false pack-objects --delta-base-offset --revs --stdout <in >/dev/null
Time (mean ± σ): 866.5 ms ± 16.2 ms [User: 1414.5 ms, System: 97.0 ms]
Range (min … max): 839.3 ms … 886.9 ms 10 runs
Benchmark 2: git.compile -c pack.readReverseIndex=true pack-objects --delta-base-offset --revs --stdout <in >/dev/null
Time (mean ± σ): 581.6 ms ± 10.2 ms [User: 1181.7 ms, System: 62.6 ms]
Range (min … max): 567.5 ms … 599.3 ms 10 runs
Summary
'git.compile -c pack.readReverseIndex=true pack-objects --delta-base-offset --revs --stdout <in >/dev/null' ran
1.49 ± 0.04 times faster than 'git.compile -c pack.readReverseIndex=false pack-objects --delta-base-offset --revs --stdout <in >/dev/null'
...and savings on trivial operations like computing the on-disk size of
a single (packed) object are even more dramatic:
$ git rev-parse HEAD >in
$ hyperfine -L v false,true 'git.compile -c pack.readReverseIndex={v} cat-file --batch-check="%(objectsize:disk)" <in'
Benchmark 1: git.compile -c pack.readReverseIndex=false cat-file --batch-check="%(objectsize:disk)" <in
Time (mean ± σ): 305.8 ms ± 11.4 ms [User: 264.2 ms, System: 41.4 ms]
Range (min … max): 290.3 ms … 331.1 ms 10 runs
Benchmark 2: git.compile -c pack.readReverseIndex=true cat-file --batch-check="%(objectsize:disk)" <in
Time (mean ± σ): 4.0 ms ± 0.3 ms [User: 1.7 ms, System: 2.3 ms]
Range (min … max): 1.6 ms … 4.6 ms 1155 runs
Summary
'git.compile -c pack.readReverseIndex=true cat-file --batch-check="%(objectsize:disk)" <in' ran
76.96 ± 6.25 times faster than 'git.compile -c pack.readReverseIndex=false cat-file --batch-check="%(objectsize:disk)" <in'
In the more than two years since e37d0b8730 was merged, Git's
implementation of on-disk reverse indexes has been thoroughly tested,
both from users enabling `pack.writeReverseIndexes`, and from GitHub's
deployment of the feature. The latter has been running without incident
for more than two years.
This patch changes Git's behavior to write on-disk reverse indexes by
default when indexing a pack, which should make the above operations
faster for everybody's Git installation after a repack.
(The previous commit explains some potential drawbacks of using on-disk
reverse indexes in certain limited circumstances, that essentially boil
down to a trade-off between time to generate, and time to access. For
those limited cases, the `pack.readReverseIndex` escape hatch can be
used).
[1]: https://github.blog/2021-04-29-scaling-monorepo-maintenance/#reverse-indexes
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Acked-by: Derrick Stolee <derrickstolee@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-04-13 00:20:33 +02:00
|
|
|
Defaults to true.
|