Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Previously
read_withValidChecksum_differentPayloadSizes
output looked like this:meaning that a stream of 256 MB payload gets read and its checksum calculated within 558 ms.
Which doesn't answer the question we are really interested in: "what overhead calculating the checksum adds?"
And secondly, it seems too much even for 256 MB. Turned out this is because the time to prepare the data was also included.
In this PR we fix that and measure:
Then we calculate the overhead of calculating checksum while reading a stream by subtracting (2) from (1).
We also do several iterations and take the median to make sure we don't take into account the runs that were affected by GC or anything else.
Here is an example of the output I got using 21 iterations:
Now we can see, for example, that enabling checksums will add ~13.5ms for reading 256 MB of response or ~7ms for 128 MB; for 32KB it is ~2.3 microseconds.
For attaching checksums to requests the overhead will be the last column (calculate checksum).