-
Notifications
You must be signed in to change notification settings - Fork 224
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
Support bytes::Bytes
& bytes::BytesMut
payloads for binary & text messaging
#465
Conversation
To make it pass `tungstenite`'s CI for min Rust version
payload: Use BytesMut as Owned
remove Payload::from_owner
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're fast! 🙂
Interesting decision to switch from ReadBuffer
to BytesMut
for the in_buffer
! It's nice that it helps to spare additional allocations (like that one with a vector that had been previously allocated just to read and return a payload from the in_buffer).
Wow that is awesome! @daniel-abramov Do you have an ETA when you plan on releasing 0.25 for tungstenite & tokio-tungstenite ? |
Published! 🎉 |
This PR builds on top of #462
Utf8Payload
for text messages backed byPayload
.Payload
forBytes
,BytesMut
&Vec
.Bytes
gives flexibility supporting shared data & cheap cloning.BytesMut
provides best read performance as we can get these from the new read buffer sans copying & unmask optimially too.Vec
provides best write performance. I couldn't getBytesMut
to perform as well even changing the bench user code. Since it doesn't increase Payload 40 bytes size it seems worth having.BytesMut
based one that can then emit payloads without copying.Payload::share
for cheap cloning.Payload::eq
compare data, so allow equality across variants.const fn from_static
to construct staticPayload
/Utf8Payload
data.The main advantage here is extending the bytes flexibility to Text types and better read performance.
Benchmarks
Write performance remains a little slower, no more than noted in the parent PR. However, read performance is significantly faster.