Is possible that decoder support PacketRef?

[simon-fu]

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], }

[pdeljanov]

Hey @simon-fu,

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:

1. Packet could become an enum of either a borrowed slice or owned Box, but that might introduce tricky lifetime problems.
2. Have a second decode function that takes a &[u8] slice or PacketRef as you described.

[fengalin]

Just wanted to note that this seems related: #109

[pdeljanov]

Just wanted to note that this seems related: #109

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.

[simon-fu]

Hey @simon-fu,

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:

1. Packet could become an enum of either a borrowed slice or owned Box, but that might introduce tricky lifetime problems.
2. 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 :)