Performance regression after adding segment type switch

[pakrym]

We've seen 10% regression in kestrel and the source seems to be that multiple ReadOnlyBuffer methods became less efficient after the change namely:

1. Seek (because of CheckBounds)
2. TryGet
3. Reader.MoveNext - I suspect mostly because of TryGet

[pakrym]

/cc @davidfowl @KrzysztofCwalina @halter73 @benaadams

[benaadams]

[benaadams]

Aside, this might be helpful https://github.com/dotnet/coreclr/issues/15755

ref struct BufferReader<TSequence> doesn't need any write barriers in it

[KrzysztofCwalina]

What was the TryGet change?

[pakrym]

Adding 3 possible types of segments (Array, OwnedMemory and IBufferList)

[pakrym]

@benaadams yeah, it generates pretty bad code around structs, and also bunch of calls to coreclr (IsArray, IsInstanceOfClass)

[benaadams]

What was the TryGet change?

Pattern matching the different types?

[KrzysztofCwalina]

I talked with @pakrym and he will try to use the high order bit in one of the Position's ints to identify the IBufferList case. Maybe we can even use the other bit to identify T[]

[benaadams]

Lose 2 bits; is still 1GB; if you need more you aren't segmenting correctly :)
Would also allow a 4th type at some point... (string for a StringBuilder type scenario?)

[halter73]

@benaadams Those of us with email notifications can see your ninja edits 😆 .

[ahsonkhan]

@pakrym, has this issue been resolved? Can it be closed?

[pakrym]

Yes. And we shouldn't track it here anymore.