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
Suppose application has a fixed buffer to store every packet data, but before invoking Decoder::decode() it must invoke Packet::new() to alloc data first. That make poor performance. Is possible that add a new type PacketRef and change decode function signature to Decoder::decode(&PacketRef) ?
The PacketRef look like: pub PacketRef<'a> { .. the same as Packet, data: &'a [u8], }
The text was updated successfully, but these errors were encountered:
I've run into the same problem too when trying to do a zero-copy decode. We could likely improve this in v0.6 since we would be making breaking changes to the API.
That being said, have you found that to be a major performance problem? Packets are generally small so the allocation should be pretty fast.
My previous ideas:
Packet could become an enum of either a borrowed slice or owned Box, but that might introduce tricky lifetime problems.
Have a second decode function that takes a &[u8] slice or PacketRef as you described.
Yep, a similar concern, but just at the output side.
Thanks for your patience regarding that PR. I'm fairly confident we can address both issues in v0.6, but I just want to get a bunch of quality and performance fixes out in v0.5.2 first.
I have many new thoughts to share on the relationship between AudioBuffers and SampleBuffers that hopefully we can use to further improve the API.
I've run into the same problem too when trying to do a zero-copy decode. We could likely improve this in v0.6 since we would be making breaking changes to the API.
That being said, have you found that to be a major performance problem? Packets are generally small so the allocation should be pretty fast.
My previous ideas:
Packet could become an enum of either a borrowed slice or owned Box, but that might introduce tricky lifetime problems.
Have a second decode function that takes a &[u8] slice or PacketRef as you described.
Thanks for reply.
I have no major performance problem. I just think that allocation on heap is expensive and zero-copy is Rustaceans' goal :)
Suppose application has a fixed buffer to store every packet data, but before invoking Decoder::decode() it must invoke Packet::new() to alloc data first. That make poor performance. Is possible that add a new type PacketRef and change decode function signature to Decoder::decode(&PacketRef) ?
The PacketRef look like:
pub PacketRef<'a> { .. the same as Packet, data: &'a [u8], }
The text was updated successfully, but these errors were encountered: