Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Tracking] Potential performance improvements #24

Open
lnicola opened this issue Dec 17, 2019 · 0 comments
Open

[Tracking] Potential performance improvements #24

lnicola opened this issue Dec 17, 2019 · 0 comments

Comments

@lnicola
Copy link
Contributor

lnicola commented Dec 17, 2019

In my quick tests, there is some room for improvement in the performance of this crate. We discussed some ideas in #23, mainly:

  • increasing the read buffer size or making it configurable
  • using BytesMut to reduce allocations
  • introducing a small amount buffering so that one chunk can be read from disk while another is being sent over the network

I'm filing this as somewhat of a tracking issue, because I don't think it's worth trying to work on it right now. The buffer size change is partially blocked because tokio limits the read size to 16 KB (tokio-rs/tokio#1976). And in my tests I couldn't get consistent performance, likely because of extra context switching in tokio (tokio-rs/tokio#1844).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant