我是否需要在foreach前检查Enumerable的Count（）

在对集合进行迭代/预览之前，是否有任何速度改进或实际上指向检查Enumerable的Count()？我是否需要在foreach前检查Enumerable的Count（）

List<int> numbers = new List<int>(); 

if(numbers.Count() > 0) 
{ 
    foreach(var i in numbers) {/*Do something*/} 
}

来源

2014-01-08 Coops

不，反之亦然。如果它不是一个集合（如List或Array），而是延迟执行的查询，它必须完全执行，这可能非常昂贵，只是为了确定计数。在你的例子中，它实际上是一个List,Enumerable.Count已经足够聪明了，可以先尝试将它转换为ICollection<T>/ICollection。如果成功使用Count属性。

所以只需使用foreach。如果序列是空的，它不会受到伤害，循环将立即退出。

出于同样的原因，如果您只想检查一个序列是否至少包含一个元素，则最好使用Enumerable.Any而不是Count() > 0。意图也更清楚。

来源

2014-01-08 08:49:33

因此，尽管这是一个侧记你的答案对于任何读者来说都是完整的，唯一你必须做的检查就是检查'null'是否有可能收集。显然在我的例子中不可能。 – Coops

@CodeBlend：应该首先完成'null'检查，如果它是方法中的一个参数，则应该用一个有意义的消息来抛出'ArgumentNullException'。 –

我不相信有任何速度的提高或迭代/ foreaching在采集前检查可枚举的Count()确实点。因为无论如何，如果集合中没有任何项目，则在该foreach块中不执行任何代码。

来源

2014-01-08 08:46:07 Coops

我同意。 'foreach'是安全的，因为如果枚举是空的，它只需要迭代0次，所以事先不需要检查（除非枚举可以是'NULL'当然！） – oerkelens

即使你要检查的次数，使用次数，而不是扩展方法Count（），因为计数的性能（）更糟糕的是再算上

来源

2014-01-08 08:49:49

@TimSchmelter所以这个答案是不正确的？ – Coops

虽然性能损失可能不是那么多，但它是糟糕的设计，它可能意味着对该对象的某种反思，并且CLR也必须为它而上，所以它总是会影响性能。 –

@CodeBlend：哎呦，我已经删除了我的评论，然后再发布你的评论。这并不正确，因为'Count'比'Count（）'更有效，但是在集合的情况下，即使使用了'Enumerable.Count'，也可以使用Count属性。但是由于必须调用另一个方法将其转换为'Collection'，直接使用'Count'会更有效，但这实际上是微优化。我更喜欢'Enumerable.Count'，因为它允许改变类型（例如改为数组或'IEnumerable '）。有时候最好“隐藏”实际类型并声明基类型f.e.以防止突变。 –

简短的回答：不，恰恰相反。
较长的回答：foreach关键字调用IEnumerator接口上的方法。这些方法隐含地检查存在的项目。所以调用Count()纯粹是多余的。

来源

2014-01-08 08:51:26

如果您的Enumarable是懒惰评估（LINQ），调用Count()实际上是非常糟糕的，因为它会评估整个Enumerable。

由于如果Enumarable为空，则不执行foreach，因此最好不要使用Count。

来源

2014-01-08 08:52:46

我是否需要在foreach前检查Enumerable的Count（）

回答

相关问题