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

Performance boost implementing poll_write_vectored and rustls 0.23 #322

Closed
stormshield-gt opened this issue Mar 6, 2024 · 2 comments
Closed

Comments

@stormshield-gt
Copy link

With new write-through API functionality of rustls 0.23 (rustls/rustls#1640), this library can implement poll_write_vectored on stream and gain a significant performance boost.

Basically, this is the same issue as in tokio-rustls rustls/tokio-rustls#26, which has a current PR to solve it rustls/tokio-rustls#45

@daniel-abramov
Copy link
Member

This won't help in our particular case as our underlying streams don't provide an implementation of vectored writes - this is caused by some known issues such as us relying solely on tungstenite-rs which was written under an assumption that streams implement Read + Write, instead of providing a sans-io implementation. But once we update the API surface of the tungstenite-rs, this would certainly be possible!

This is also one of the reasons why alternatives such as fastwebsockets are more performant.

@agalakhov
Copy link
Member

This could indeed be implemented with future versions of Rust. One needs something like https://rust-lang.github.io/rfcs/1210-impl-specialization.html in order to switch between implementations for different streams. With that, one could implement a simple I/O for generic streams and scatter-gather I/O for less generic ones. With the current version of Rust it is however impossible to use the vectored feature of some advanced streams without losing the possibility to work with any stream that has Read+Write.

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

No branches or pull requests

3 participants