You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 23, 2022. It is now read-only.
Since processing of packets is likely to happen thousands of times per second, there will be a performance gain if the struct doesn't allocate to Vec<> every time you unmarshal a header.
I do agree about reducing the number of heap allocations, but in a future context I think arrayvec is not advisable because it makes the futures themselves too large. Further, I think it complicates achieving cancel safety since the stack gets dropped when a future is cancelled.
The cancel safety point is equally true for naive heap allocations of course.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Since processing of packets is likely to happen thousands of times per second, there will be a performance gain if the struct doesn't allocate to Vec<> every time you unmarshal a header.
Something like arrayvec would be suitable for this: https://crates.io/crates/arrayvec
The text was updated successfully, but these errors were encountered: