Bug 44719 - Mcs does not take advantage of struct enumerator optimization that roslyn does
Summary: Mcs does not take advantage of struct enumerator optimization that roslyn does
Status: RESOLVED INVALID
Alias: None
Product: Compilers
Classification: Mono
Component: C# ()
Version: unspecified
Hardware: PC Mac OS
: --- normal
Target Milestone: ---
Assignee: Marek Safar
URL:
Depends on:
Blocks:
 
Reported: 2016-09-25 03:07 UTC by Marius Ungureanu
Modified: 2016-09-25 04:05 UTC (History)
2 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on GitHub or Developer Community with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED INVALID

Description Marius Ungureanu 2016-09-25 03:07:37 UTC
Details here: https://commentout.net/drafts/ifastenumerable.html

Important part:
> List<T> actually takes advantage of a little-known optimization available for foreach included in C#: when running on IEnumerable<T>, foreach normally invokes IEnumerable<T>.GetEnumerator(). But, if the type has a property named Enumerator and that property returns a type that structurally matches the IEnumerator<T> interface, foreach will use that instead. List<T> has all of this, so this path is used whenever foreach is called on a list directly. Aside from saving the IEnumerable<T> interface dispatch (about 2-4 times more expensive than a standard call) it also allows the enumerator type to be a struct without boxing (allocation is also very expensive). With the enumerator as a struct it also helps with inlining, especially if the fields are promoted to registers.

As can be seen, there is a nested List<T>.Enumerator struct defined in reference source
https://github.com/mono/mono/blob/master/mcs/class/referencesource/mscorlib/system/collections/generic/list.cs#L1149

I can't find the relevant source code in Roslyn which handles this, but it might be worth looking into.
Comment 1 Marius Ungureanu 2016-09-25 03:08:28 UTC
Adding a leading > will lead to text not being wrapped, sorry.

List<T> actually takes advantage of a little-known optimization available for foreach included in C#: when running on IEnumerable<T>, foreach normally invokes IEnumerable<T>.GetEnumerator(). But, if the type has a property named Enumerator and that property returns a type that structurally matches the IEnumerator<T> interface, foreach will use that instead. List<T> has all of this, so this path is used whenever foreach is called on a list directly. Aside from saving the IEnumerable<T> interface dispatch (about 2-4 times more expensive than a standard call) it also allows the enumerator type to be a struct without boxing (allocation is also very expensive). With the enumerator as a struct it also helps with inlining, especially if the fields are promoted to registers.
Comment 2 Miguel de Icaza [MSFT] 2016-09-25 03:48:38 UTC
From the discussion on Slack:

Jared: "I believe @ameya should have written “But if a type has a method named GetEnumerator and that return type structurally matches …""
Comment 3 Miguel de Icaza [MSFT] 2016-09-25 03:58:33 UTC
It seems like the blog post is incorrect in stating that there is special handling for an "Enumerator" property, based on reading Roslyn.   It is possible that the problem is elsewhere.
Comment 4 Marius Ungureanu 2016-09-25 04:05:38 UTC
Closing as non-bug. The problem was that our binaries were compiled before refsource import of collections, so enumerators were being allocated.