Array.FindAll improvements

[Henr1k80]

I found that there were room for improvement in Array.FindAll

Now a small amount of matches are stack allocated and the List is only optionally allocated.

It is always faster with less allocations.

The stack allocated size can be made bigger, but it is fixed size, so it will have a price for no-match schenarios.

InlineArray16<T> is only in .NET 10, but if this should be backported to .NET 8, we can create our local InlineMatchArrayX

BenchmarkDotNet v0.15.4, Windows 11 (10.0.26200.6584)
Intel Core i7-10750H CPU 2.60GHz (Max: 2.59GHz), 1 CPU, 12 logical and 6 physical cores
.NET SDK 10.0.100-rc.1.25451.107
[Host]               : .NET 10.0.0 (10.0.0-rc.1.25451.107, 10.0.25.45207), X64 RyuJIT x86-64-v3
.NET 10.0            : .NET 10.0.0 (10.0.0-rc.1.25451.107, 10.0.25.45207), X64 RyuJIT x86-64-v3

Method	Size	Mean	Error	StdDev	Ratio	RatioSD	Gen0	Allocated	Alloc Ratio
NewFindAllMatchAlways	1	10.050 ns	6.3250 ns	0.3467 ns	0.38	0.02	0.0051	32 B	0.31
OldFindAllMatchAlways	1	26.206 ns	24.8534 ns	1.3623 ns	1.00	0.06	0.0166	104 B	1.00
NewFindAllMatchAlways	16	36.170 ns	9.8894 ns	0.5421 ns	0.48	0.01	0.0140	88 B	0.29
OldFindAllMatchAlways	16	75.915 ns	18.0667 ns	0.9903 ns	1.00	0.02	0.0484	304 B	1.00
NewFindAllMatchAlways	17	52.152 ns	9.3427 ns	0.5121 ns	0.52	0.02	0.0267	168 B	0.36
OldFindAllMatchAlways	17	101.104 ns	61.4162 ns	3.3664 ns	1.00	0.04	0.0739	464 B	1.00
NewFindAllMatchHalf	1	10.394 ns	3.0844 ns	0.1691 ns	0.43	0.03	0.0051	32 B	0.31
OldFindAllMatchHalf	1	24.386 ns	36.3012 ns	1.9898 ns	1.00	0.10	0.0166	104 B	1.00
NewFindAllMatchHalf	16	28.195 ns	13.3802 ns	0.7334 ns	0.55	0.02	0.0089	56 B	0.30
OldFindAllMatchHalf	16	51.558 ns	36.7246 ns	2.0130 ns	1.00	0.05	0.0293	184 B	1.00
NewFindAllMatchHalf	17	30.810 ns	6.4918 ns	0.3558 ns	0.40	0.03	0.0102	64 B	0.23
OldFindAllMatchHalf	17	77.267 ns	112.9780 ns	6.1927 ns	1.00	0.10	0.0446	280 B	1.00
NewFindAllMatchNever	1	2.626 ns	1.5578 ns	0.0854 ns	0.52	0.04	-	-	0.00
OldFindAllMatchNever	1	5.021 ns	6.4986 ns	0.3562 ns	1.00	0.09	0.0051	32 B	1.00
NewFindAllMatchNever	16	8.160 ns	0.9575 ns	0.0525 ns	0.86	0.02	-	-	0.00
OldFindAllMatchNever	16	9.492 ns	3.7944 ns	0.2080 ns	1.00	0.03	0.0051	32 B	1.00
NewFindAllMatchNever	17	8.574 ns	8.8062 ns	0.4827 ns	0.64	0.10	-	-	0.00
OldFindAllMatchNever	17	13.646 ns	47.8793 ns	2.6244 ns	1.02	0.23	0.0051	32 B	1.00

[huoyaoyuan]

Thanks you for your contribution. The code is not performing well with best practices. Instead, just replace the List with ValueListBuilder and add a Dispose call to the builder will serve you all the optimizations.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-runtime
See info in area-owners.md if you want to be subscribed.

[huoyaoyuan]

There may be more unintentional affect after rethinking. ArrayPool<T> is quite heavy for each T, especially when the pool is not widely shared. That's also why the BCL only uses ArrayPool over limited set of types (byte, char and other integers). Even ArrayPool<object> is never used in BCL.

Initializing the array pool for each T has not acceptable overhead to whole program. Microbenchmark improvement doesn't result in benefit to whole program. This PR could not be accepted because of this.

[Henr1k80]

There may be more unintentional affect after rethinking. ArrayPool<T> is quite heavy for each T, especially when the pool is not widely shared. That's also why the BCL only uses ArrayPool over limited set of types (byte, char and other integers). Even ArrayPool<object> is never used in BCL.

Initializing the array pool for each T has not acceptable overhead to whole program. Microbenchmark improvement doesn't result in benefit to whole program. This PR could not be accepted because of this.

SegmentedArrayBuilder uses ArrayPool<T> and SegmentedArrayBuilder is used within LINQ