Use System.Buffers

[benaadams]

Use System.Buffers to reduce memory consumption; ctors would need Return in dispose; though mostly streams so have a dispose available.

OwinWebSocketAdapter.CloseAsync
Microsoft.AspNetCore.WebUtilities.BufferedReadStream.ctor
Microsoft.AspNetCore.WebUtilities.FormReader.ctor (variable initialized)
Microsoft.AspNetCore.WebUtilities.HttpRequestStreamReader.ctor
Microsoft.AspNetCore.WebUtilities.HttpResponseStreamWriter.ctor
Microsoft.AspNetCore.WebUtilities.MultipartReaderStream.Read
Microsoft.AspNetCore.WebUtilities.MultipartReaderStream.ReadAsync
Microsoft.AspNetCore.WebUtilities.StreamHelperExtensions.DrainAsync
Microsoft.AspNetCore.WebUtilities.WebEncoders.Base64UrlDecode
Microsoft.AspNetCore.WebUtilities.WebEncoders.Base64UrlEncode
Microsoft.Net.Http.Headers.ContentDispositionHeaderValue.TryDecode5987

Can't be done as relies on the byte array size

Microsoft.AspNetCore.Http.SessionExtensions.SetInt32

[muratg]

@DamianEdwards RC2 or later?

cc @sajayantony

[DamianEdwards]

@muratg if we have capacity to take this one now, then please do so. Need to ensure we capture some numbers for some scenarios that use the types listed above first of course so we get good indication of improvements.

[benaadams]

I can shoot you a PR in under an hour if you can take the CR and measurement side?

[benaadams]

Its PR #550

[sajayantony]

This would be interesting to measure. Does the ArrayPool.Shared have thread/core affinity optimization. Reading the Return method indicates it has a spin lock on every take. This also means that they would end up on the gen2 heap. and when you have high core core count I wonder if the per proc heap will be an issue. We did a lot of optimization in classes like the BufferManager
I guess measuring on a high core machine will be only way to validate this.

Also given that the ArrayPool shared has 1MB buffers and only 50 of them wouldn't this hit allocation path a lot if and that too with 1MBor am i reading it wrong 😟

Basically enabling some kind of control not the size depending on the scenario might be an interesting thing to consider.

/cc @KrzysztofCwalina

[benaadams]

Also given that the ArrayPool shared has 1MB buffers and only 50 of them wouldn't this hit allocation path a lot if and that too with 1MB or am i reading it wrong

Is a doc/comment issue, though you are in good company for reading it this way aspnet/Benchmarks#44 (comment)

I currently understand this to be max 50 arrays pooled per bucket; buckets up to a max size of 1MB, buckets lazily allocated and sizes starting at 16 and going up in powers of 2; 16, 32, 64, 128 etc.

Some greater clarity is being provided for the comments: dotnet/corefx#5863

Reading the Return method indicates it has a spin lock on every take.

SpinLocks are done at the bucket level rather than the pool level

This also means that they would end up on the gen2 heap.

Ideal since they are reused for lifetime of app.

I guess measuring on a high core machine will be only way to validate this.

More generally; outside of System.Buffers in aspnetcore testing I've found core counts of 16 to perform very well (e.g. 2.6M+ rps and > 12GBps for larger requests) when on a single socket.

When you move to multi-socket on a Azure VM; (e.g. 2x16 32 cores vs 1x16 and 2x8 16 cores vs 1x8) performance isn't as good as a single socket - though still high.

However, there could be many reasons for this and kernel time is much higher in this situation; so probably a first step would be to run two processes socket affinitized to rule out O/S+NIC related concerns as it is at > 2GBps data rate with millions of winsock calls per second and see there is perf doubling in this shared nothing state.

If its process related - well that's a much longer discussion for a different issue...

[muratg]

#595