contrib/fuzz/fuzzutil.cc

cborutil: change buffering strategy

Profiling revealed that we were spending a lot of time on the
line that was concatenating the old buffer with the incoming data
when attempting to decode long byte strings, such as manifest
revisions.

Essentially, we were feeding N chunks of size len(X) << len(Y) into
decode() and continuously allocating a new, larger buffer to hold
the undecoded input. This created substantial memory churn and
slowed down execution.

Changing the code to aggregate pending chunks in a list until we
have enough data to fully decode the next atom makes things much
more efficient.

I don't have exact data, but I recall the old code spending >1s
on manifest fulltexts from the mozilla-unified repo. The new code
doesn't significantly appear in profile output.

Differential Revision: https://phab.mercurial-scm.org/D4854

#include "fuzzutil.h"

#include <cstring>
#include <utility>

contrib::optional<two_inputs> SplitInputs(const uint8_t *Data, size_t Size)
{
	if (!Size) {
		return contrib::nullopt;
	}
	// figure out a random point in [0, Size] to split our input.
	size_t left_size = (Data[0] / 255.0) * (Size - 1);

	// Copy inputs to new allocations so if bdiff over-reads
	// AddressSanitizer can detect it.
	std::unique_ptr<char[]> left(new char[left_size]);
	std::memcpy(left.get(), Data + 1, left_size);
	// right starts at the next byte after left ends
	size_t right_size = Size - (left_size + 1);
	std::unique_ptr<char[]> right(new char[right_size]);
	std::memcpy(right.get(), Data + 1 + left_size, right_size);
	LOG(2) << "inputs are  " << left_size << " and " << right_size
	       << " bytes" << std::endl;
	two_inputs result = {std::move(right), right_size, std::move(left),
	                     left_size};
	return result;
}