StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
10342669
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
1
CommunityOwnedDate
CreationDate
2012-04-26T23:09:04.973
FavoriteCount
0
LastActivityDate
2012-04-26T23:09:04.973
LastEditDate
LastEditorUserId
0
OwnerUserId
1286670
ParentId
10126460
PostTypeId
2
Score
1
ViewCount
0
LastEditorDisplayName
text
Body
Short answer: It is because <a href="http://msdn.microsoft.com/en-us/library/8bs2ecf4%28v=vs.100%29.aspx" rel="nofollow">CRL</a> has optimization for dispatching methods called on interface-type. As long as particular interface's method call is made on the same type (that implements this interface), CLR uses fast dispatching routine (only 3 instructions) that only checks actual type of instance and in case of match it jumps directly on precomputed address of particular method. But when the same interface's method call is made on instance of another type, CLR switches dispatching to slower routine (which can dispatch methods for any actual instance type). Long answer: Firstly, take a look at how the method <a href="http://msdn.microsoft.com/en-us/library/system.linq.enumerable.sum.aspx" rel="nofollow">System.Linq.Enumerable.Sum()</a> is declared (I omitted validity checking of source parameter because it's not important it this case): <pre><code>public static int Sum(this IEnumerable<int> source) { int num = 0; foreach (int num2 in source) num += num2; return num; } </code></pre> So all types that implement <a href="http://msdn.microsoft.com/en-us/library/9eekhta0.aspx" rel="nofollow">IEnumerable< int ></a> can call this extension method, including int[] and List< int >. Keyword <a href="http://msdn.microsoft.com/en-us/library/ttw7t8t6%28v=vs.100%29.aspx" rel="nofollow">foreach</a> is just abbreviation for getting enumerator via IEnumerable< T >.GetEnumerator() and iterating through all values. So this method actually does this: <pre><code> public static int Sum(this IEnumerable<int> source) { int num = 0; IEnumerator<int> Enumerator = source.GetEnumerator(); while(Enumerator.MoveNext()) num += Enumerator.Current; return num; } </code></pre> Now you can clearly see, that method body contains three method calls on interface-type variables: GetEnumerator(), MoveNext(), and Current (although Current is actually property, not method, reading value from property just calls corresponding getter method). GetEnumerator() typically creates new instance of some auxiliary class, which implements IEnumerator< T > and thus is able to return all values one by one. It is important to note, that in case of int[] and List< int >, types of enumerators returned by GetEnumerator() ot these two classes are different. If argument source is of type int[], then GetEnumerator() returns instance of type SZGenericArrayEnumerator< int > and if source is of type List< int >, then it returns instance of type List< int >+Enumerator< int >. Two other methods (MoveNext() and Current) are repeatedly called in tight loop and therefore their speed is crucial for overall performance. Unfortunatelly calling method on interface-type variable (such as IEnumerator< int >) is not as straightforward as ordinary instance method call. CLR must dynamically find out actual type of object in variable and then find out, which object's method implements corresponding interface method. CLR tries to avoid doing this time consuming lookup on every call with a little trick. When particular method (such as MoveNext()) is called for the first time, CLR finds actual type of instance on which this call is made (for example SZGenericArrayEnumerator< int > in case you called Sum on int[]) and finds address of method, that implements corresponding method for this type (that is address of method SZGenericArrayEnumerator< int >.MoveNext()). Then it uses this information to generate auxiliary dispatching method, which simply checks, whether actual instance type is the same as when first call was made (that is SZGenericArrayEnumerator< int >) and if it is, it directly jumps to the method's address found earlier. So on subsequent calls, no complicated method lookup is made as long as type of instance remains the same. But when call is made on enumerator of different type (such as List< int >+Enumerator< int > in case of calculating sum of List< int >), CLR no longer uses this fast dispatching method. Instead another (general-purpose) and much slower dispatching method is used. So as long as Sum() is called on array only, CLR dispatches calls to GetEnumerator(), MoveNext(), and Current using fast method. When Sum() is called on list too, CLR switches to slower dispatching method and therefore performance decreases. If performance is your concern, implement your own separate Sum() extension method for every type, on which you want to call Sum(). This ensures that CLR will use fast dispatching method. For example: <pre><code>public static class FasterSumExtensions { public static int Sum(this int[] source) { int num = 0; foreach (int num2 in source) num += num2; return num; } public static int Sum(this List<int> source) { int num = 0; foreach(int num2 in source) num += num2; return num; } } </code></pre> Or even better, avoid using IEnumerable< T > interface at all (because it's still brings noticeable overhead). For example: <pre><code>public static class EvenFasterSumExtensions { public static int Sum(this int[] source) { int num = 0; for(int i = 0; i < source.Length; i++) num += source[i]; return num; } public static int Sum(this List<int> source) { int num = 0; for(int i = 0; i < source.Count; i++) num += source[i]; return num; } } </code></pre> Here are results from my computer: <ul> <li>Your original program: 9844, 9841, 12545, 14384</li> <li>FasterSumExtensions: 6149, 6445, 754, 6145</li> <li>EvenFasterSumExtensions: 1557, 1561, 553, 1574</li> </ul>
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POwhy in this simple test the speed of method relates to the order of triggering?
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. This table or related slice is empty.
UserOwnerUserId
1. USŇuf
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. POwhy in this simple test the speed of method relates to the order of triggering?
 singulars
 PostTypePostTypeId
 PTQuestion
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTAcceptedByOriginator
3. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTBountyClose
CommentsPostId
1. CODoes it does harm to the speed of myArray.Sum() if I run myList.ToArray() before hand? even in different scope?
 singulars
 PostPostId
 PO
 UserUserId
 UScolinfang

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.