bench: reuse the buffers across iterations - #95
Open
francisdb wants to merge 3 commits into
Open
Conversation
The read benches only covered memory, which hides the per-call cost of an unbuffered File. Add a disk read group with a short measurement window.
Every iteration wrote into, or read into, a freshly allocated Vec, and for the large sizes the kernel mapping that memory cost several times the copy itself. Create the file buffer, the source data and the read sink once per case so the numbers cover the crate.
The two rows then read directly against each other: what separates them is the per-stream overhead and the cache behaviour of 1 MiB buffers.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Builds on #94 (its commit is included here until it merges).
Every iteration wrote into, or read into, a freshly allocated
Vec. For the large sizes the kernel mapping that memory costs several times the copy itself, so those rows measured "fill a new buffer" more than the crate: on my machine a 256 MiB copy into a freshVectakes 57 ms against 11 ms into a resident one.Each case now creates its file buffer, source data and read sink once and reuses them, cleared rather than freed, across iterations. The disk write group still creates a fresh temp file per iteration, since that is part of writing to disk.
The small cases are unchanged.
The second commit replaces the 50 x 1 MiB case with 256 x 1 MiB, so that row carries the same bytes as the single 256 MiB stream and the two read directly against each other. With the reused buffers: write to memory 14 ms against 18 ms, read from memory 12 ms against 22 ms, write to disk 116 ms against 106 ms. The many-stream side wins in memory because 1 MiB buffers stay in cache; the single stream wins on disk because each extra stream costs a directory entry and its FAT links.