理解扩展 ElementAt(index)
考虑这段代码：
int size = 100 * 1000 * 1000;
var emu = Enumerable.Range(0, size);
var arr = Enumerable.Range(0, size).ToArray();
当我调用 emu.ElementAt(size-10) 和 arr.ElementAt(size-10) 并测量 arr 的时间要快得多（与 IEnumerable 0.59s 相比，数组为 0.0002s）。
据我了解，扩展方法 ElementAt() 具有签名
public static TSource ElementAt<TSource>(this IEnumerable<TSource> source, int index)
，并且由于“源”是 IEnumerable，因此执行的逻辑将类似 - 与我所看到的直接访问数组的情况相反。
有人可以解释一下吗:)
Consider this code:
int size = 100 * 1000 * 1000;
var emu = Enumerable.Range(0, size);
var arr = Enumerable.Range(0, size).ToArray();
when I call emu.ElementAt(size-10) and arr.ElementAt(size-10) and measure the time the arr is much faster (the array is 0.0002s compared to IEnumerable 0.59s).
As I understand it, the extention method ElementAt() have the signature
public static TSource ElementAt<TSource>(this IEnumerable<TSource> source, int index)
and since the 'source' is a IEnumerable the logic carried out would be similar - opposed to what I see where the array is accessed directly.
Could someone please explain this :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在
IEnumerable上调用ElementAt将循环遍历项目，直到到达所需的索引。 （O(n) 操作）在
IList（例如数组）上调用ElementAt将使用IList的索引器立即获得所需的索引。 （O(1) 操作）Calling
ElementAton anIEnumerable<T>will loop through the items until it reaches the desired index. (An O(n) operation)Calling
ElementAton anIList<T>(such as an array) will use theIList<T>'s indexer to immediately get the desired index. (An O(1) operation)这是在执行时执行的优化。尽管调用未重载，但它可以检查（使用
is或as）源是否实际上是IList。如果是，它就能够直接转到正确的元素。其他各种调用都可以执行此操作 - 值得注意的是
Count()，它针对ICollection和（从 .NET 4 开始）非泛型ICollection进行了优化界面。扩展方法的缺点之一是所有这些优化都必须由实现本身执行 - 类型不能覆盖任何内容来“选择加入”优化扩展方法。这意味着原始实现者必须知道所有优化:(
This is an optimization performed at execution-time. Although the call isn't overloaded, it is able to check (using
isoras) whether the source is actually anIList<T>. If it is, it's able to go directly to the right element.Various other calls do this - notable
Count()which is optimised forICollection<T>and (as of .NET 4) the nongenericICollectioninterface.One of the downsides of extension methods is that all these optimizations have to be performed by the implementation itself - types can't override anything to "opt in" to optimizing extension methods. That means the optimizations have to all be known by the original implementor :(