Allocations in FileBufferingReadStream

[rynowak]

It would be nice to use buffer-pooling for buffering of form-data. This shows up as perf-sensitive in a bunch of MVC scenarios:

If we're not going to use the pool for this, we could consider choosing an initial size based on the Content-Length (with a limit of course). The above shows reallocations (3000 requests).

[Tratcher]

RE: #545

[davidfowl]

/cc @sajayantony

[sajayantony]

😨 per request MemoryStreams
Given that it is a REPLAY type stream it would definitely be worth pooling and you already dispose file resources on clean up, so the semantic already exists in FileBufferingReadStream

[rynowak]

/cc @dougbu - we were looking at implementing a pooling memory stream in antiforgery as well

[muratg]

@DamianEdwards Do we want to take more perf improvements in RC2?

[DamianEdwards]

@muratg if we have capacity to (i.e. devs have no other work pertaining to moving to .NET Core CLI and getting our core scenarios working) then by all means.

[benaadams]

Should be resolved by #550, except when content is buffered to disk; which needs this issue resolving in corefx dotnet/corefx#5598

This is due to FileStream's internal buffer is not being exposed/settable.

[benaadams]

The buffer pool changes in #550 (superseded by #556) mean these allocations are greatly reduced

e.g. for 30,000 requests - byte[] allocations are as follows 0.5MB on rent vs 440MB on MemoryStream originally

[muratg]

Nice!

[Tratcher]

bd60507