使用"大量"LINQ to Objects语句有什么缺点吗？

Question

我来自Java编程并切换到C#编程我发现了LINQ的极端强大功能.

在我最近的实现中,我注意到我经常在我的代码中使用它(特别是LINQ to Objects)来避免foreach循环,搜索列表中的元素以及类似的任务.

现在我想知道在大量使用Linq to Objects时是否存在一些性能劣势......

Answer 1

Linq比本机C#循环慢.
C#比C++慢.
C++比程序集慢.
装配比设计自定义微处理器慢.

所以你应该总是设计自己的定制微处理器,而不是使用Linq .....

是否有性能受损？可能,但在实际测量它之前你不会知道多少.这可能是足够小,它不会很显著,你可以花,你将花费避免LINQ的解决应用程序的那部分时间做的优化中受益.

底线是 - 使用最有效率的库和框架构建您的应用程序,然后从那里进行优化.您可能会发现应用程序中最慢的部分根本不是Linq代码,所以如果您因为它可能比滚动自己的循环更慢而禁止它,那么您将优化错误的东西.

Answer 2

为了客观地回答你的问题,LINQ大量使用委托和迭代器,它们具有实例化(委托和迭代器)和方法调用(委托调用和MoveNext()迭代器)的开销.现在,a foreach(on List<T>)将具有迭代器的开销,但不会占用委托的开销.所以预计LINQ在这里要慢一些foreach.

同样,使用[i]索引器迭代列表预计会更快,因为它也没有迭代器的开销.更快的是不使用List<T>数组而是数组.但即便如此,也会产生数组边界检查的开销(IndexOutOfRangeException如果你试图超出数组边界则抛出一个数字),这可以通过指针使用原始内存访问,或者简单地迭代整个列表来避免(for(var i = 0; i < array.Length; i++) { Console.WriteLine(array[i]); }不会有)边界检查,因为编译器可以证明这个循环永远不会超出界限).

这些是各种迭代方式带来的不同程度的开销.那些管理费用是否重要？如果您正在进行10,000 x 10,000矩阵乘法,那么是.否则,可能不会,除非你已经测量过它(这是一个疲惫不堪的旧答案,但同样有效).

但是,除了这些事实之外,你如何使用它们也很重要.假设您想要一个1980年以后出生的客户列表,这些客户来自更多的客户并对其进行进一步处理.如果没有LINQ,您将非常被迫foreach使用原始客户列表,并创建一个中间列表,将1980年以后出生的客户放入其中.使用 LINQ,您将不需要中间列表,这可以节省大量开销(创建列表,调用Add在它上面,随着它的增长最有可能调整几次)并且可能更快.而且它的内存效率肯定更高,因为1980年以后出生的客户一个接一个地"流式传输"而没有中间列表占用内存.使用LINQ,您可以处理无限长的序列.

使用LINQ的另一个性能原因是某些操作的并行化AsParallel()在查询结束时调用变得微不足道.

因此,如果使用LINQ存在性能劣势,请回答您的问题:

这取决于.