Fix an incorrect analysis / comment in the "pattern doubling" code.

This should have a miniscule positive effect on performance; the
main idea of the CL is just to fix the incorrect comment.
This commit is contained in:
scrubbed 2018-01-16 13:39:18 -08:00 committed by Victor Costan
parent e69d9f8806
commit 15a2804cd2
1 changed files with 8 additions and 11 deletions

View File

@ -152,7 +152,7 @@ inline char* IncrementalCopy(const char* src, char* op, char* const op_limit,
assert(op <= op_limit);
assert(op_limit <= buf_limit);
// NOTE: The compressor always emits 4 <= len <= 64. It is ok to assume that
// to optimize this function but we have to also handle these cases in case
// to optimize this function but we have to also handle other cases in case
// the input does not satisfy these conditions.
size_t pattern_size = op - src;
@ -182,16 +182,13 @@ inline char* IncrementalCopy(const char* src, char* op, char* const op_limit,
// Handle the uncommon case where pattern is less than 8 bytes.
if (SNAPPY_PREDICT_FALSE(pattern_size < 8)) {
// Expand pattern to at least 8 bytes. The worse case scenario in terms of
// buffer usage is when the pattern is size 3. ^ is the original position
// of op. x are irrelevant bytes copied by the last UnalignedCopy64.
//
// abc
// abcabcxxxxx
// abcabcabcabcxxxxx
// ^
// The last x is 14 bytes after ^.
if (SNAPPY_PREDICT_TRUE(op <= buf_limit - 14)) {
// If plenty of buffer space remains, expand the pattern to at least 8
// bytes. The way the following loop is written, we need 8 bytes of buffer
// space if pattern_size >= 4, 11 bytes if pattern_size is 1 or 3, and 10
// bytes if pattern_size is 2. Precisely encoding that is probably not
// worthwhile; instead, invoke the slow path if we cannot write 11 bytes
// (because 11 are required in the worst case).
if (SNAPPY_PREDICT_TRUE(op <= buf_limit - 11)) {
while (pattern_size < 8) {
UnalignedCopy64(src, op);
op += pattern_size;