I found related issue #978, but unless I'm missing something obvious I don't see a way to serialize directly into the buffer without knowing the length of the message in advance. Which leads to an unnecessary memory copy.
Would it make sense to add something like this to Msg? This way I could do InitPool to get an oversize buffer, then serialize my data straight into it as well as setting the Sizeafter the fact. All with the safety of not having dangling references to the buffer that may change the contents before it goes on the wire.
public void Fill(Func<int, Span<byte>> filler)
{
Size = filler(m_data.AsSpan());
}
The above should be improved with better names and one or two safety (bounds) checks, but the general idea is this simple, I think. Also seems a lot safer and cleaner than simply making the Size publicly settable.
Would there be interest in (me) making this into a pull request? Thanks.
We're always interested in pull requests that improve the library. I would advise against changing the existing API (extending it is fine) so that we maintain backward compatibility.
I found related issue #978, but unless I'm missing something obvious I don't see a way to serialize directly into the buffer without knowing the length of the message in advance. Which leads to an unnecessary memory copy.
Would it make sense to add something like this to
Msg
? This way I could doInitPool
to get an oversize buffer, then serialize my data straight into it as well as setting theSize
after the fact. All with the safety of not having dangling references to the buffer that may change the contents before it goes on the wire.The above should be improved with better names and one or two safety (bounds) checks, but the general idea is this simple, I think. Also seems a lot safer and cleaner than simply making the
Size
publicly settable.Would there be interest in (me) making this into a pull request? Thanks.