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.
Rationale of the change
I selected most frictionless bit to change. It was fs read/write.
I didn't improve read that much but I focused on write. Writes are improved as you saw below. I am 100% sure vectored writes are even faster.
Tests are passing locally. No public API change except
async_read
module rename andNucleiReader
rename. Tbh,NucleiReader
rename is also bad. I wanted to call itAsyncReader
but it will get confused withAsyncRead
trait.Some Roadmap Items
futures-util
andfutures-lite
.futures::Async*
drop all Tokio read-likes.Bytes
.spawn_
code in actual async context so user should do these. It is not our problem to manage async io on behalf of the user. Don't incorporate runtime's hardcoded methods if not necessary. (some storage APIs are actually require it, we still keep for them.)epoll
andkqueue
should be selectable by features.#[nuclei::test]
,#[nuclei::bench]
etc.Performance
Full benchmark results against master:
https://gist.github.com/vertexclique/cd1307d38210bec2d5e3b768502daef0
If bufs fits in memory we are getting immense performance:
Bench PDF: exact_buf_write_256 KiB - Criterion.rs.pdf