Object store rents 128k ends up in LOH

[mtmk]

Proposed change

When saving (and potentially loading) objects from object store we allocate 128K chunks of memory from array pool for publishing. This would create arrays larger than 85K ending up in LOH. We need to be able to write multiple slices of memory to socket when publishing or read on subscriptions. A memory sequence type can be used for this at least for binary serialization.

Thanks to @MiloszKrajewski for pointing it out.

Use case

Avoid LOH

Contribution

No response

[MiloszKrajewski]

I kind of gave you idea which is not that simple.
According to this it is actually desired behaviour.

RecyclableMemoryStream improves GC performance by ensuring that the larger buffers used for the streams are put into the gen 2 heap and stay there forever. This should cause full collections to happen less frequently. If you pick buffer sizes above 85,000 bytes, then you will ensure these are placed on the large object heap, which is touched even less frequently by the garbage collector.

YMMV and "rule no 1 of performance is 'measure'"