Use custom collector to avoid intermediate array allocations

[mgravell]

Context #2166

List<T> uses initial-size plus doubling, which means that for large result sets you can get multiple arrays, for example for 90 rows you might have arrays with sizes 16, 32, 64, and 128 for 90, with the final result list using the oversized 128-element array, with 90 elements.

This change uses a custom collector for this part - same logic, but it uses the array-pool so that those intermediate arrays are recycled, and the final array is right-sized, i.e. a list with count 90 and capacity 90, and all intermediate arrays reused.

[TimothyMakkison]

Hey, glad to see someone's working on this.

Have you considered using a stackallocated scratchbuffer for the inital buffer. This pattern is used in both ValueListBuilder and SegmentedArrayBuilder, the latter of which is used internally for Linq for tasks that are very similar to dappers.

// similar to ValueListBuilder
var buffer = new Collector<T>([defaut, default, defaut, default, defaut, default, defaut, default]);

// similar to SegmentedArrayBuilder
Collector<TSource>.ScratchBuffer scratch = default;
Collector<TSource> builder = new Collector<T>(scratch);

[mgravell]

Interesting suggestion. I'll find a moment to look; obviously only suitable for sync path, though.

[mgravell]

Obviously it would also only apply in limited scenarios, i.e. the same rules as unmanaged

[TimothyMakkison]

Interesting suggestion. I'll find a moment to look; obviously only suitable for sync path, though.

Yeah, I thought that it might be suitable for functions that used AsList. I did think that there were areas where ValueListBuilder could be used in Dapper iirc relating to DynamicParameters. I can't imagine the performance gain being large.