Use spawn_blocking directly to read from files #25
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.
Code is rough, and not sure if this is a good idea. Just playing around with ideas in #24.
This bypasses
tokio::fs
and directly usesspawn_blocking
inspired by Tokio internals. This allows us to skip Tokio's internal buffering, and read directly into our ownBytesMut
.It looks like, at least on macOS, the OS will fill whatever size buffer we give it.
Some relative results on my own machine using the example server with:
ab -n 1000 -c 10 http://127.0.0.1:3000/search-index.js
(an 975K file), and tweaking our ownBUF_SIZE
:These numbers are really shifty, though. But what I do find interesting is that there's an apparent ~13% increase comparing the two runs with 8 KB buffers.
Besides skipping a copy, the other thing I thought might make a difference is the change in
open_with_metadata
. Through Tokio internals, we previously did separatespawn_blocking
calls for the open and stat steps there, but I combined these in this PR. To try eliminate this, I split the new code into two manualspawn_blocking
calls and got these numbers:So that only accounts for maybe ~1.5% of that 13% gain.
cc @lnicola