LINQ 有 2 种计算可枚举数的方法：Count and LongCount。实际上，这两者之间的唯一区别是第一个返回一个int，而第二个返回一个long.
我不清楚为什么添加第二种方法。它的唯一用例似乎是处理超过 2B 元素的枚举。对我来说，这似乎是一个糟糕的决定，原因如下：
大多数 BCL 集合都由单维数组支持，这些数组的长度保证适合int。试图超越这一点会引发OverflowException / OutOfMemoryException.
LongCount是 O(n) 因为IEnumerable很懒。如果你有一个可枚举的 3B 元素，你可以调用LongCount，然后再次迭代它（如果您想使用任何值，则必须这样做），您将添加额外的 3B 迭代，这将非常慢，并向开发人员隐藏它。
其他 LINQ 操作，例如ToArray / ToList，由于 (1)，不支持具有 2B+ 元素的可枚举。
我在这里错过了什么，还是有更实际的原因LongCount加入？谢谢。
我对这个设计决策没有第一手的了解，但我可以提供一个有根据的猜测。
该方法对于IQueryable;该查询可以轻松地由巨大的数据库表支持。
我希望
IQueryable<Foo> q = whatever;
long result1 = q.LongCount();
long result2 = q.AsEnumerable().LongCount();
产生相同的答案。要求内存中查询使用返回不同类型的不同方法似乎是有悖常理的，特别是当实现可枚举版本非常容易时。
但正如我所说，这是一个有根据的猜测。希望真正从事此设计的人可能会插话。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
