diff options
author | Derrick Stolee <dstolee@microsoft.com> | 2021-03-26 12:38:11 +0000 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2021-03-26 14:32:45 -0700 |
commit | ddaf1f62e3090335e6973911062a9cf70673c06f (patch) | |
tree | 92071ad9a1ddd7ef6827330296c84e74b7b2c0c1 /pack-bitmap.h | |
parent | Git 2.31 (diff) | |
download | tgif-ddaf1f62e3090335e6973911062a9cf70673c06f.tar.xz |
csum-file: make hashwrite() more readable
The hashwrite() method takes an input buffer and updates a hashfile's
hash function while writing the data to a file. To avoid overuse of
flushes, the hashfile has an internal buffer and most writes will use
memcpy() to transfer data from the input 'buf' to the hashfile's buffer
of size 8 * 1024 bytes.
Logic introduced by a8032d12 (sha1write: don't copy full sized buffers,
2008-09-02) reduces the number of memcpy() calls when the input buffer
is sufficiently longer than the hashfile's buffer, causing nr to be the
length of the full buffer. In these cases, the input buffer is used
directly in chunks equal to the hashfile's buffer size.
This method caught my attention while investigating some performance
issues, but it turns out that these performance issues were noise within
the variance of the experiment.
However, during this investigation, I inspected hashwrite() and
misunderstood it, even after looking closely and trying to make it
faster. This change simply reorganizes some parts of the loop within
hashwrite() to make it clear that each batch either uses memcpy() to the
hashfile's buffer or writes directly from the input buffer. The previous
code relied on indirection through local variables and essentially
inlined the implementation of hashflush() to reduce lines of code.
Helped-by: Jeff King <peff@peff.net>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'pack-bitmap.h')
0 files changed, 0 insertions, 0 deletions