-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Several changes to reduce allocations #11273
base: main
Are you sure you want to change the base?
Conversation
Related to #11160 |
/// </example> | ||
/// <typeparam name="T">The item type that is enumerated.</typeparam> | ||
/// <param name="collection">The collections that will be enumerated.</param> | ||
/// <returns>The enumerator for the collection.</returns> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If foreach
can be optimised this way - shouldn't it be something that should be part of compiler/runtime? Are we possible missing on any already existing opportunity there? @stephentoub?
Or is this bringing benefit only on NetFx? (in which case we migh possibly want to conditionaly compile it only for NetFx?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This appears to be trying to manually special-case a few specific collection types by maintaining a discriminated union of all of their strongly-typed struct enumerators. I would not be surprised if this actually makes things more expensive in various situations, especially on .NET Core where dynamic PGO (on by default as of .NET 8) will already do such special-casing and handle devirtualizing and inlining the enumerator dispatches. In .NET 10 the enumerator allocation itself will also frequently be avoided thanks to stack allocation / escape analysis work currently being done by @AndyAyersMS.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The intent with this helper is to selectively apply it in situations where the allocations are significant, so I'd be hesitant to unconditionally apply it for reasons that @stephentoub mentions. Anecdotally, I've applied this change in a couple of places and reverted the change because I saw an increase in CPU cost that wasn't offset by the reduction in allocations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Gotcha.
Sounds helpful on NetFX. We should probably measure impact on dotnet build
(core) though
Is the plan to split this PR into several smaller ones still in place please? |
Fixes #
Context
There is an appreciable amount of time all of the MSBuild process nodes spend doing GC during a build. Taking steps to reduce allocations. This PR contains a mix of approaches that reduce allocations in several areas.
Changes Made
Testing
Notes