Investigate optimizing ArrayPool heuristics

[jkotas]

Now that the ArrayPool is part of CoreLib, we may be able to better optimize its heuristics - make it aware of GCs happening, etc.

See dotnet/coreclr#7734 (comment)

[swgillespie]

@joshfree @danmosemsft would either of you know if there are any existing performance tests for a Stream instance that would exercise ArrayPoolCopyToAsync, so we can measure our optimizations?

[danmoseley]

I am not familiar with the corefx perf tests. @weshaggard

[joshfree]

@brianrob @billwert may be able to dig up some closed-source perf desktop tests for you

[jkotas]

ArrayPool is recent invention. There are unlikely going to be desktop tests that exercise it.

I believe that CopyToAsync that is implemented using ArrayPool is exercised by ASP.NET branchmarks that serve a static file.

Related to this: There are several redundant memory pools implementation throughout the .NET Core stack - ASP.NET Core has MemoryPoolSlab and friends. It may be interesting to look into whether there is anything to gain by replacing these with the built-in pool intead.

[jkotas]

It may be also interesting to look into per-thread (or even better per-core) caches of the memory blocks. It was hard to do well when ArrayPool was standalone, but it may be more feasible now that the ArrayPool is in corelib.

[jkotas]

We may consider skipping GC zero-initialization for large arrays allocate via ArrayPool. Related discussion at dotnet/coreclr#16749 (comment)

[danmoseley]

@JeremyKuhne is going to find some mitigation for 2.1, and explore a longer term solution for post 2.1. Let's track with this issue.

[Maoni0]

I am fine with not having GC clear the memory for large buffers - as a matter of fact for any large object, it's fine to have some way to tell the GC to not clear memory. the GCHeap::Alloc APIs already take a flag - you could indicate something in the flags.

[Maoni0]

I am going to close this issue as there are already more detailed ones.

corefx dotnet/coreclr#25841 tracks the BCL portion.
dotnet/coreclr#17324 and dotnet/coreclr#17325 are to track skipping initialization for large objects.

and I will be checking in the new GC API for providing memory info to BCL.