Is there a way to avoid heap allocating for every message sent/received?

[jgarvin]

In the example read_message and write_message deal with the Message type, which contains a bunch of owning types (either String or Vec<u8>) rather than references. AFAICT this means you can't just reuse the same buffer in place over and over, and have to make fresh allocations every message. Is there a way around this?

[agalakhov]

I had this idea but did not implement it due to minor performance impact on modern allocators. They handle this situation (freeing and then reallocating) quite well. Reusing buffers makes ownership handling more difficult since you can't receive anything until previous message is processed and you can't just keep incoming messages in memory. Choosing between simpler API and potentially slightly better performance I choose the API.

Could you measure or estimate the performance impact? Is it really worth implementing?

[jgarvin]

I suspect you wouldn't hit the happy path in allocators because your allocation size is going to vary based on message length. Whether the performance hit is significant is going to depend on what the application requires, allocator implementation and the pattern of allocations between messages. Any allocation can trigger system calls to request more memory from the OS which can be expensive for some applications. What I can say for sure is that if you support an API that doesn't allocate, you can always build a more convenient API that does allocate on top of it, but you can't do it the other way around.

You could maybe minimize the API pain by having Message (contains references) that impls Into<OwningMessage>. That still makes it fairly straightforward to store messages if that's what users want to do. Another overhead users could avoid here would be if Text messages were still u8 slices instead of str or String, and let users opt-in to the conversion (which may not be necessary for say a blind message forwarding process).

[aldanor]

you can't receive anything until previous message is processed and you can't just keep incoming messages in memory

Unless some sort of arena allocator is used internally?

[vorner]

I wonder if the way forward would be to use the Bytes. One can chunk off multiple of them from one BytesMut and if they are freed soon enough, they just return back into the original BytesMut (on call to reserve). But they can also be passed on to the sending end. And even prost is going to support zero-copy parsing from Bytes.

The Text one can use some kind of wrapper, like this one.

[daniel-abramov]

It seems like the original questions have been answered, so I'm going to close the issue.

Feel free to open a new one or re-open the existing one if you plan to turn it into feature / work on a PR.