The change

- static StackExchange.Redis.Lease<T>.Create(int length, bool clear = true) -> StackExchange.Redis.Lease<T>!
+static StackExchange.Redis.Lease<T>.Create(int length, bool clear = true, System.Buffers.ArrayPool<T>? pool = null) -> StackExchange.Redis.Lease<T>!

is a hard "nope" - that would smash binary compatibility; at the minimum, we would need to add this via an overload. However, I wonder whether we should instead allow the least to be backed by a union of T[] / IMemoryOwner<T> (presumably via a single object field), and for the byte case we might use the existing response buffer. Thoughts?

for the byte case we might use the existing response buffer. Thoughts?

perfect!

I have updated Lease, but I am having trouble passing the IMemoryOwner object to the ResultProcessor<Lease>

I can look tomorrow, but I assume it would be accessing the muxer via the connection to get the options, to pass into a new overload of AsLease

ok, I have a plan here; merging this into my branch and evolving

new approach summary (please weigh in here!)

• options has MemoryPool<byte>? ResponseBufferPool and RequestBufferPool - they are no longer "exotic" types
• if specified, type-testing is used to check for the new CycleBufferPool<T> which would allow you to add your own rules based on ReadOnlySequence<T> (which means the implementation has access to total size, last buffer size, number of buffers, etc), when accessed via CycleBuffer
• the Lease<byte> code also uses ResponseBufferPool, but the simple Rent(int) is used, not the ReadOnlySequence<T> version

Does that cover all bases?

new approach summary (please weigh in here!)

• options has MemoryPool<byte>? ResponseBufferPool and RequestBufferPool - they are no longer "exotic" types
• if specified, type-testing is used to check for the new CycleBufferPool<T> which would allow you to add your own rules based on ReadOnlySequence<T> (which means the implementation has access to total size, last buffer size, number of buffers, etc), when accessed via CycleBuffer
• the Lease<byte> code also uses ResponseBufferPool, but the simple Rent(int) is used, not the ReadOnlySequence<T> version

I like. But I have a few comments:

1. Why are you getting a response buffer from RequestBufferPool? Is this not an error?

-var memoryPool = BridgeCouldBeNull?.Multiplexer.RawConfig.ResponseMemoryPool ?? MemoryPool<byte>.Shared;
+var memoryPool = BridgeCouldBeNull?.Multiplexer.RawConfig.RequestBufferPool ?? MemoryPool<byte>.Shared;

2. I thought you suggested setting the memoryOwner buffer (for the Lease class), which was received the first time, to call the OnResponseFrame method.

var memoryOwner = memoryPool.Rent(len);
Span<byte> oversized = memoryOwner.Memory.Span.Slice(0, len);

payload.CopyTo(oversized);

OnResponseFrame(prefix, oversized, ref memoryOwner);

memoryOwner?.Dispose();

Does that cover all bases?

3. That's enough for now. But I have last year's issuer Memory optimization for ScriptEvaluate #2843, and I would like to include it in the next iteration.

1 yep, typo, thanks

2 I'll have to read when at a computer, my brain can't parse in isolation

1 yep, typo, thanks

2 I'll have to read when at a computer, my brain can't parse in isolation

OK. I think the current changes are sufficient for a release. When can we expect a new version?

typo fixed; re 2 - there's two different concepts here; can I check we're not talking past each-other?

The Lease<byte> scenario returns to things like StringGetLease, where the memory is being passed to the caller; however, the OnResponseFrame citation is referring to the core processing logic, in particular: the relatively rare scenario where a discontiguous buffer has been retrieved, and we're linearizing it for processing; these are completely separate things, so I'm confused what point you're making. I don't mean this negatively: I am curious - I just don't want to misunderstand you.

On releases: I'll see if I can get a point release out today

typo fixed; re 2 - there's two different concepts here; can I check we're not talking past each-other?

The Lease<byte> scenario returns to things like StringGetLease, where the memory is being passed to the caller; however, the OnResponseFrame citation is referring to the core processing logic, in particular: the relatively rare scenario where a discontiguous buffer has been retrieved, and we're linearizing it for processing; these are completely separate things, so I'm confused what point you're making. I don't mean this negatively: I am curious - I just don't want to misunderstand you.

Yes, you are right. I didn't know that the scenario of getting a large buffer from a sequence of segments is rare.
I'll look into this point more closely.

On releases: I'll see if I can get a point release out today

Great!