-
Notifications
You must be signed in to change notification settings - Fork 4.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix Enumerable.Chunk throughput regression #72811
Conversation
Tagging subscribers to this area: @dotnet/area-system-linq Issue DetailsWe previously changed the implementation of Enumerable.Chunk to avoid significantly overallocating in the case of the chunk size being a lot larger than the actual number of elements. We instead switched to a doubling scheme ala
|
We previously changed the implementation of Enumerable.Chunk to avoid significantly overallocating in the case of the chunk size being a lot larger than the actual number of elements. We instead switched to a doubling scheme ala `List<T>`, and I pushed for us to just use `List<T>` to keep things simple. However, in doing some perf measurements I noticed that for common cases Chunk is now around 20% slower in throughput than it was previously, which is a bit too much too swallow, and the code that just uses an array directly isn't all that much more complicated; it also affords the ability to avoid further overallocation when doubling the size of the storage, which should ideally be capped at the chunk size. This does so and fixes the throughput regression.
3685687
to
492834f
Compare
private IEnumerable<int> _source = new int[1_000];
[Benchmark]
[Arguments(10)]
[Arguments(100)]
public void Chunk(int chunkSize)
{
foreach (int[] _ in _source.Chunk(chunkSize)) { }
}
|
We previously changed the implementation of Enumerable.Chunk to avoid significantly overallocating in the case of the chunk size being a lot larger than the actual number of elements. We instead switched to a doubling scheme ala
List<T>
, and I pushed for us to just useList<T>
to keep things simple. However, in doing some perf measurements I noticed that for common cases Chunk is now around 20% slower in throughput than it was previously, which is a bit too much too swallow, and the code that just uses an array directly isn't all that much more complicated; it also affords the ability to avoid further overallocation when doubling the size of the storage, which should ideally be capped at the chunk size. This does so and fixes the throughput regression enough (not completely).