Any plans to use MemoryPool when deserializing ByteString?

[wolf8196]

This is a question in regards to .NET implementation of protocol buffers.
I started using protobuf together with gRPC, so sorry, if I'm missing the bigger picture or don't take other use cases into account.

Considering the big number of guides & tutorials (including MSDN) recommending to use ArrayPool or MemoryPool to minimize memory allocations and improve performance, I was wondering why ByteString doesn't use the memory from MemoryPool?

I saw that recently there was a PR that changed ByteString to use memory and added unsafe create without copy.
This allows to rent the memory from pool, create ByteString, send it, and release the memory.
This should be beneficial for client side, but on server side, it's the protobuf's code that does the allocation, and it currently creates an array for the whole field.

So back to the question: are there any plans to rent the memory from the pool for ByteStrings, and let the users dispose of it once they are done? Or is there a reason why it's a bad idea? Or will the benefits actually be so small, that it's not worth the effort?

[jtattermusch]

The fundamental problem is that currently ByteString (or any other objects for representing protobuf fields / messages) doesn't provide an API for disposing the underlying values, which makes the scenario of renting memory from a pool a returning it non-intuitive and it's easy to get things wrong and either leak memory or erroneously read from memory that was already returned to the pool.

#7645 was mostly introduced for advanced and "use at your own risk" scenarios, not as a general purpose API that everyone should use. Using the new API you can achieve renting the byteStrings for some scenarios when you really need to (and after you've measured it's worth it), but as was pointed out in that PR's thread already, using it in your day-to-day usage of protobufs is not recommended (because there's no way of controlling the lifecycle of the rented memory).