ee1f0c242e
The previous change allowed skipping the hashing portion of the hashwrite API, using it instead as a buffered write API. Disabling the hashwrite can be particularly helpful when the write operation is in a critical path. One such critical path is the writing of the index. This operation is so critical that the sparse index was created specifically to reduce the size of the index to make these writes (and reads) faster. This trade-off between file stability at rest and write-time performance is not easy to balance. The index is an interesting case for a couple reasons: 1. Writes block users. Writing the index takes place in many user- blocking foreground operations. The speed improvement directly impacts their use. Other file formats are typically written in the background (commit-graph, multi-pack-index) or are super-critical to correctness (pack-files). 2. Index files are short lived. It is rare that a user leaves an index for a long time with many staged changes. Outside of staged changes, the index can be completely destroyed and rewritten with minimal impact to the user. Following a similar approach to one used in the microsoft/git fork [1], add a new config option (index.skipHash) that allows disabling this hashing during the index write. The cost is that we can no longer validate the contents for corruption-at-rest using the trailing hash. [1]21fed2d914We load this config from the repository config given by istate->repo, with a fallback to the_repository if it is not set. While older Git versions will not recognize the null hash as a special case, the file format itself is still being met in terms of its structure. Using this null hash will still allow Git operations to function across older versions. The one exception is 'git fsck' which checks the hash of the index file. This used to be a check on every index read, but was split out to just the index ina33fc72fe9(read-cache: force_verify_index_checksum, 2017-04-14) and released first in Git 2.13.0. Document the versions that relaxed these restrictions, with the optimistic expectation that this change will be included in Git 2.40.0. Here, we disable this check if the trailing hash is all zeroes. We add a warning to the config option that this may cause undesirable behavior with older Git versions. As a quick comparison, I tested 'git update-index --force-write' with and without index.skipHash=true on a copy of the Linux kernel repository. Benchmark 1: with hash Time (mean ± σ): 46.3 ms ± 13.8 ms [User: 34.3 ms, System: 11.9 ms] Range (min … max): 34.3 ms … 79.1 ms 82 runs Benchmark 2: without hash Time (mean ± σ): 26.0 ms ± 7.9 ms [User: 11.8 ms, System: 14.2 ms] Range (min … max): 16.3 ms … 42.0 ms 69 runs Summary 'without hash' ran 1.78 ± 0.76 times faster than 'with hash' These performance benefits are substantial enough to allow users the ability to opt-in to this feature, even with the potential confusion with older 'git fsck' versions. Test this new config option, both at a command-line level and within a submodule. The confirmation is currently limited to confirm that 'git fsck' does not complain about the index. Future updates will make this test more robust. It is critical that this test is placed before the test_index_version tests, since those tests obliterate the .git/config file and hence lose the setting from GIT_TEST_DEFAULT_HASH, if set. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
44 lines
1.9 KiB
Plaintext
44 lines
1.9 KiB
Plaintext
index.recordEndOfIndexEntries::
|
|
Specifies whether the index file should include an "End Of Index
|
|
Entry" section. This reduces index load time on multiprocessor
|
|
machines but produces a message "ignoring EOIE extension" when
|
|
reading the index using Git versions before 2.20. Defaults to
|
|
'true' if index.threads has been explicitly enabled, 'false'
|
|
otherwise.
|
|
|
|
index.recordOffsetTable::
|
|
Specifies whether the index file should include an "Index Entry
|
|
Offset Table" section. This reduces index load time on
|
|
multiprocessor machines but produces a message "ignoring IEOT
|
|
extension" when reading the index using Git versions before 2.20.
|
|
Defaults to 'true' if index.threads has been explicitly enabled,
|
|
'false' otherwise.
|
|
|
|
index.sparse::
|
|
When enabled, write the index using sparse-directory entries. This
|
|
has no effect unless `core.sparseCheckout` and
|
|
`core.sparseCheckoutCone` are both enabled. Defaults to 'false'.
|
|
|
|
index.threads::
|
|
Specifies the number of threads to spawn when loading the index.
|
|
This is meant to reduce index load time on multiprocessor machines.
|
|
Specifying 0 or 'true' will cause Git to auto-detect the number of
|
|
CPU's and set the number of threads accordingly. Specifying 1 or
|
|
'false' will disable multithreading. Defaults to 'true'.
|
|
|
|
index.version::
|
|
Specify the version with which new index files should be
|
|
initialized. This does not affect existing repositories.
|
|
If `feature.manyFiles` is enabled, then the default is 4.
|
|
|
|
index.skipHash::
|
|
When enabled, do not compute the trailing hash for the index file.
|
|
This accelerates Git commands that manipulate the index, such as
|
|
`git add`, `git commit`, or `git status`. Instead of storing the
|
|
checksum, write a trailing set of bytes with value zero, indicating
|
|
that the computation was skipped.
|
|
+
|
|
If you enable `index.skipHash`, then Git clients older than 2.13.0 will
|
|
refuse to parse the index and Git clients older than 2.40.0 will report an
|
|
error during `git fsck`.
|