使用集合时,我有两种获取对象计数的方法:Count (属性)和Count() (方法)。有人知道它们的主要区别是什么吗?
我可能错了,但我总是在任何条件语句中使用Count属性,因为我假设Count()方法对集合执行某种类型的查询,其中必须在我“获取”之前已经分配了as Count。但这只是一个猜测--我不知道如果我错了,性能是否会受到影响。
编辑:出于好奇,如果集合为空,Count()会抛出异常吗?因为我非常确定Count属性只返回0。
发布于 2011-11-02 00:18:00
反编译Count()扩展方法的源代码表明,它测试对象是否为ICollection (泛型或其他类型),如果是,则简单地返回底层Count属性:
因此,如果您的代码访问Count而不是调用Count(),则可以绕过类型检查-这是一个理论上的性能好处,但我怀疑这是否会是一个明显的好处!
// System.Linq.Enumerable
public static int Count<TSource>(this IEnumerable<TSource> source)
{
checked
{
if (source == null)
{
throw Error.ArgumentNull("source");
}
ICollection<TSource> collection = source as ICollection<TSource>;
if (collection != null)
{
return collection.Count;
}
ICollection collection2 = source as ICollection;
if (collection2 != null)
{
return collection2.Count;
}
int num = 0;
using (IEnumerator<TSource> enumerator = source.GetEnumerator())
{
while (enumerator.MoveNext())
{
num++;
}
}
return num;
}
}发布于 2012-10-04 00:23:39
性能只是选择其中之一的一个原因。选择.Count()意味着您的代码将更加通用。我曾经遇到过这样的情况:我重构了一些不再生成集合的代码,取而代之的是一些更通用的代码,比如IEnumerable,但结果是其他代码崩溃了,因为它依赖于.Count,我不得不将其更改为.Count()。如果我指出在任何地方都使用.Count(),代码可能会更加可重用和可维护。通常选择使用更通用的接口,如果你能摆脱它是你最好的选择。我所说的更通用,是指由更多类型实现的更简单的接口,因此可以在代码之间实现更好的兼容性。
我并不是说.Count()更好,我只是说还有其他考虑因素更多地处理您正在编写的代码的可重用性。
发布于 2011-11-02 00:16:05
.Count()方法可能足够智能,或者知道有问题的类型,如果是这样的话,它可能会使用底层的.Count属性。
话又说回来,可能不会。
我要说的是,如果集合本身有一个.Count属性,那么就性能而言,这将是您最好的选择。
如果.Count()方法不知道该集合,它将枚举该集合,这将是一个O(n)操作。
https://stackoverflow.com/questions/7969354
复制相似问题