[release/10.0-rc1] Introduce size-optimized IListSelect iterator #118829
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
This lets us keep some of the constant-time indexing advantages of the IList iterator, without the GVM overhead of Select. There is a small size increase here, but nowhere near the cost of the GVM. In a pathological generated example for GVMs the cost was: 1. .NET 9: 12 MB 2. .NET 10 w/out this change: 2.2 MB 3. .NET 10 w/ this change: 2.3 MB In a real-world example (AzureMCP), the size attributed to System.Linq was: 1. .NET 9: 1.2 MB 2. .NET 10 w/out this change: 340 KB 3. .NET 10 w/ this change: 430 KB This seems like a good tradeoff. We mostly keep the algorithmic complexity the same across the size/speed-opt versions, and just tradeoff on the margins. We could probably continue to improve this in the future.
Co-authored-by: Copilot <[email protected]>
Co-authored-by: Stephen Toub <[email protected]>
Co-authored-by: Stephen Toub <[email protected]>
This takes a more aggressive direction and removes the size optimized versions of iterators for Skip and Take. As far as I can tell these are relatively small size increases, but using them preserves the O(1) optimizations in the ' speed' version.
These are more (relatively common) cases where you could end up with an O(n) implementation instead of O(1) even when the backing enumerable is capable of doing O(1) index access.
jeffschwMSFT
approved these changes
Aug 18, 2025
|
@MichalStrehovsky mind reviewing the backport? |
artl93
approved these changes
Aug 18, 2025
artl93
added
Servicing-approved
This was referenced Aug 19, 2025
Open
MichalStrehovsky
approved these changes
Aug 19, 2025
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Backport of #118156 to release/10.0-rc1
/cc @agocke
Customer Impact
This is a bug fix for a LINQ regression in .NET 10 Native AOT caused by adopting the size-optimized version of some operators. This PR adjusts the size-optimized version of LINQ to have better computational complexity for a few operations, at the cost of (hopefully) small size increases.
We would ideally have this change in RC1 to ensure that these hypothesis are correct: that this addresses the most likely regression areas, and does not significantly increase the size.
Regression
Testing
Manual validation and unit tests.
Risk
Low. This PR mostly copies existing code from the mainline codepaths or removes special casing entirely, to use the standard coreclr code paths.