Investigate leveraging ArrayPool

[rokonec]

We are introducing ArrayPool in #6705.

By quick analyze I have identified following areas which might leverage from buffers pool.

• InterningBinaryReader._buffer - Since _buffer is used only in ReadString we can simplify code, delete _buffer and its initialization from call stacks and just Rent\Return buffer of destination string size in the ReadString method.
• Avoid BinaryReader.ReadBytes and related Translate(ref byte[] byteArray) - good candidate is TargetResult.TranslateItems
• Consider using RecyclableMemoryStream (or some equivalent using ArrayPool.Shared) in places where our current usage of MemoryStream is allocating a lot.
• Others - yet to be identified.

[rokonec]

Although we can replace public void Translate(ref byte[] byteArray) by public void Translate(ref byte[] byteArray, ref int length) its actual allocation portion is < 0.09%

[rokonec]

Using RecyclableMemoryStream would not bring as much gain as originally though. Our code already uses somehow shared MemoryStream in most hot places.

We would more leverage from using reusable BinaryReader and/or BinaryWritter as we create both classes for every packet and both classes lazy allocates couple of working buffers.

[rokonec]

I have not identified other places where using ArrayPool would bring measurable performance benefit.

[rokonec]

@ladipro @AR-May
Please check my conclusion. Lets discuss sometimes if we want to invest into reusable BinaryReader and/or BinaryWritter as started above.

[ladipro]

@rokonec thank you, what you wrote makes perfect sense. Is it possible to quantify the impact of building a reusable BinaryReader and BinaryWriter? In terms of % of allocations saved when building a large solution, or something similar.

[rokonec]

@ladipro I was mislead by dotMemory tool I am evaluating. I expected percentage was from overall memory but it was from given type - in this case byte[]
I have measured it again and and it is bellow 0.1% of memory usage I do not longer recommend to invest into it.

Sorry for this mistake.