Fixed ArrayPoolBufferWriter<T> repeated new[] allocations

[Sergio0694]

PR Type

What kind of change does this PR introduce?

• Optimization

What is the current behavior?

The ArrayPoolBufferWriter<T> uses the given ArrayPool<T> instance to resize its internal buffer when needed, which only works as expected when the array itself is small. The issue is that the ArrayPool<T>.Shared instance has an internal threshold set to 1024 * 1024, over which it just allocates new arrays every time to avoid keeping very large arrays alive for a long time. That is perfectly fine, except for one little detail: once you get past that threshold, ArrayPool<T>.Shared stops rounding up the requested size. It instead returns an array with new[] of exactly the requested size, which absolutely kills the performance when used in a writer type like ArrayPoolBufferWriter<T>: this means that as soon as we get past tha threshold, we'll basically end up resizing the whole array for every single new write operation, no matter how large it is. That's super bad for performance and memory usage 🥺

What is the new behavior?

The solution for this is pretty simple, this PR includes a simple check for the requested size, and if that's over 1024 * 1024 it just rounds that up to the closest power of 2, so that the array size will effectively just keep being multiplied by 2 every time. This has a huge performance impact when eg. trying to use the ArrayPoolBufferWriter<T> class to write a 10MB buffer, 8KB at a time:

Method	Mean	Error	StdDev	Ratio	Gen 0	Gen 1	Gen 2	Allocated
Before	1,380.236 ms	19.9806 ms	17.7122 ms	1.000	355000.0000	355000.0000	355000.0000	5754.44 MB
After	8.820 ms	0.1757 ms	0.4838 ms	0.006	640.6250	640.6250	640.6250	30 MB

In this simple benchmark alone, the updated version is 156x faster and uses 190x less memory 😄
Of course, results will vary a lot on the specific workload, but you can imagine the impact being even more dramatic when working with larger buffers, or with less items being written at any given time. With this change in general, users will not have to worry about the size of the data being written, and the class will automatically use the right approach in all cases.

PR Checklist

Please check if your PR fulfills the following requirements:

• Tested code with current supported SDKs
• Pull Request has been submitted to the documentation repository instructions. Link:
• Sample in sample app has been added / updated (for bug fixes / features)
  • Icon has been created (if new sample) following the Thumbnail Style Guide and templates
• Tests for the changes have been added (for bug fixes / features) (if applicable)
• Header has been added to all new source files (run build/UpdateHeaders.bat)
• Contains NO breaking changes

[ghost]

Thanks Sergio0694 for opening a Pull Request! The reviewers will test the PR and highlight if there is any conflict or changes required. If the PR is approved we will proceed to merge the pull request 🙌

[ghost]

Hello @michael-hawker!

Because this pull request has the auto merge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.