From: Derrick Stolee <dstolee@xxxxxxxxxxxxx>
In an independent investigation, I noticed that do_write_index() in
read-cache.c has its own hashing logic and buffering mechanism.
Specifically, the ce_write() method was introduced by 4990aadc (Speed up
index file writing by chunking it nicely, 2005-04-20) and similar
mechanisms were introduced a few months later in c38138cd
(git-pack-objects: write the pack files with a SHA1 csum, 2005-06-26).
Based on the timing, in the early days of the Git codebase, I figured
that these roughly equivalent code paths were never unified only because
it got lost in the shuffle. The hashfile API has since been used
extensively in other file formats, such as pack-indexes,
mult-pack-indexes, and commit-graphs. Therefore, it seems prudent to
unify the index writing code to use the same mechanism.
However, upon doing that refactoring process, I noticed that this caused
some commands that write the index to slow down by 1-2%! I then looked
for a reason why this could be.
First, I noticed that the mechanisms use different buffer sizes. The
hashfile uses an 8KB buffer while the index uses an 128KB buffer.
Testing with a variety of different buffer sizes made little difference.
Next, I inspected the buffering code itself, and found an important
difference. Specifically, every call to hashwrite() was causing a flush
of the filestream, even if it was a very small write. With many callers
using helpers like hashwrite_be32() to write integers in network-byte
order, this was leading to many more file flushes than necessary.
This change modifies hashwrite() to always populate the hashfile buffer,
and only flush when that buffer is full. This is safe to do because all
consumers of a hashfile must call finalize_hashfile(), which flushes the
buffer at the start.
It is worth noting that this is modifying logic introduced by a8032d12
(sha1write: don't copy full sized buffers, 2008-09-02) which reduces
memcpy() calls when the input buffer is sufficiently longer than the
hashfile's buffer, causing nr to be the length of the full buffer. Use
the input buffer directly in these cases. Since we don't guarantee that
the buffer is flushed by the end of hashwrite(), we need to group some
offset logic into the condition that memcpy() is necessary. Note that nr
is equal to sizeof(f->buffer) only when f->offset is zero, so that
condition does not need to be added here.
As for performance, I focused on known commands that spend a significant
amount of time writing through the hashfile API, especially if using
small buffers as in hashwrite_be32(). 'git multi-pack-index write' was
an excellent example (deleting the multi-pack-index file between runs)
and demonstrated this performance change in the Linux kernal repo:
Benchmark #1: old
Time (mean ± σ): 2.229 s ± 0.143 s [User: 1.409 s, System: 0.327 s]
Range (min … max): 2.160 s … 2.636 s 10 runs
Benchmark #2: new
Time (mean ± σ): 2.162 s ± 0.005 s [User: 1.392 s, System: 0.323 s]
Range (min … max): 2.152 s … 2.172 s 10 runs
Summary
'new' ran
1.03 ± 0.07 times faster than 'old'
Similarly, the same command on the Git repository gave these numbers:
Benchmark #1: old
Time (mean ± σ): 230.5 ms ± 6.3 ms [User: 140.5 ms, System: 42.9 ms]
Range (min … max): 221.7 ms … 240.6 ms 12 runs
Benchmark #2: new
Time (mean ± σ): 220.6 ms ± 5.1 ms [User: 139.5 ms, System: 34.1 ms]
Range (min … max): 214.0 ms … 229.0 ms 13 runs
Summary
'new' ran
1.05 ± 0.04 times faster than 'old'
Finally, to demonstrate that performance holds when frequently using
large buffers, the numbers below are for 'git pack-objects' packing all
objects in the Git repository between v2.30.0 and v2.31.1:
Benchmark #1: old
Time (mean ± σ): 1.003 s ± 0.045 s [User: 1.877 s, System: 0.167 s]
Range (min … max): 0.931 s … 1.044 s 10 runs
Benchmark #2: new
Time (mean ± σ): 976.4 ms ± 42.2 ms [User: 1.854 s, System: 0.192 s]
Range (min … max): 940.1 ms … 1049.3 ms 10 runs
Summary
'new' ran
1.03 ± 0.06 times faster than 'old'
With these consistent improvements of 3-5%, it will be possible to move
the index writing logic over to hashfile without performance
degradation.
Signed-off-by: Derrick Stolee <dstolee@xxxxxxxxxxxxx>
---
csum-file: flush less often
I found this while poking around the index.
Thanks, -Stolee
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-914%2Fderrickstolee%2Fhashfile-flush-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-914/derrickstolee/hashfile-flush-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/914
csum-file.c | 22 ++++++++--------------
1 file changed, 8 insertions(+), 14 deletions(-)
diff --git a/csum-file.c b/csum-file.c
index 0f35fa5ee47c..39644af590a5 100644
--- a/csum-file.c
+++ b/csum-file.c
@@ -89,32 +89,26 @@ int finalize_hashfile(struct hashfile *f, unsigned char *result, unsigned int fl
void hashwrite(struct hashfile *f, const void *buf, unsigned int count)
{
while (count) {
- unsigned offset = f->offset;
- unsigned left = sizeof(f->buffer) - offset;
+ unsigned left = sizeof(f->buffer) - f->offset;
unsigned nr = count > left ? left : count;
- const void *data;
if (f->do_crc)
f->crc32 = crc32(f->crc32, buf, nr);
if (nr == sizeof(f->buffer)) {
/* process full buffer directly without copy */
- data = buf;
+ the_hash_algo->update_fn(&f->ctx, buf, nr);
+ flush(f, buf, nr);
} else {
- memcpy(f->buffer + offset, buf, nr);
- data = f->buffer;
+ memcpy(f->buffer + f->offset, buf, nr);
+ f->offset += nr;
+ left -= nr;
+ if (!left)
+ hashflush(f);
}
count -= nr;
- offset += nr;
buf = (char *) buf + nr;
- left -= nr;
- if (!left) {
- the_hash_algo->update_fn(&f->ctx, data, offset);
- flush(f, data, offset);
- offset = 0;
- }
- f->offset = offset;
}
}
base-commit: 142430338477d9d1bb25be66267225fb58498d92
--
gitgitgadget
