LINQ应该尽量避免，因为它是慢？ [英] Should LINQ be avoided because it's slow?
问题描述
我已经被告知，由于.NET的LINQ是如此之慢，我们不应该使用它，并想知道其他人也拿出了同样的结论，并例子是：
接过1443ms做的10亿相比非LINQ。
拿了4944ms做10亿相比之下，LINQ。
（较慢的243％）
非LINQ code：
的for（int i = 0; I＆LT; 10000;我++）
{
的foreach（在LST1 MyLinqTestClass1项目）// 100000项列表
{
如果（item.Name ==9999）
{
isInGroup = TRUE;
打破;
}
}
}
接过1443ms做的10亿相比非LINQ。
LINQ code：
的for（int i = 0; I＆LT; 10000;我++）
isInGroup = lst1.Cast＆LT; MyLinqTestClass1＆GT;（）任何（项目=＆GT; item.Name ==9999）;
接过4944ms做10亿相比之下，LINQ。
我猜它可能优化LINQ code，但想法是，它很容易得到很慢LINQ code和给定的，它不应该被使用。鉴于LINQ是慢那么它也将遵循PLINQ是缓慢和NHibernate LINQ将是缓慢等LINQ声明任何种类不应使用。
有没有其他人发现，LINQ是缓慢的希望，他们从来没有使用过它，或者是将我们可以做出基于这样一个标准过于笼统脑震荡？
LINQ的应该尽量避免，因为它的慢？
没有。应该可以避免的，如果它的不够快的。 慢和不够快的根本不是一回事！
慢的是无关你的客户，你的管理，你的利益相关者。 不够快的是非常相关的。从来没有衡量的快速的东西;告诉你什么，你可以用它来立足于一个商业决定。测量的如何接近于接受客户的是。如果可以接受，然后停止更快的使它花钱;它已经够用了。
性能优化的价格昂贵的。写作code，以便它可以读取和其他人保持是的价格昂贵的。这些目标常常在相互对立的，所以为了花你的利益相关者的钱负责，你一定要确保你只花费宝贵的时间和精力做的事情性能优化是的不够快。
您已经找到了一个人为的，不切实际的基准情况下LINQ code是比写的code的一些其他的方式要慢。我向你保证，你的客户不在乎讲讲你不切实际的基准速度。他们只关心你运送到它们的程序对他们来说是太慢了。我向你保证，你的管理不关心一些有关这个（如果他们是主管）;他们关心多少钱，你花不必要做的东西，是的速度不够快的unnoticably更快，使得code更昂贵的阅读，理解，并在此过程中维护。
I've had been told that since .net linq is so slow we shouldn't use it and was wondering anyone else has come up with the same conclusion, and example is:
Took 1443ms to do 1000000000 compares non-LINQ.
Took 4944ms to do 1000000000 compares with LINQ.
(243% slower)
the non-LINQ code:
for (int i = 0; i < 10000; i++)
{
foreach (MyLinqTestClass1 item in lst1) //100000 items in the list
{
if (item.Name == "9999")
{
isInGroup = true;
break;
}
}
}
Took 1443ms to do 1000000000 compares non-LINQ.
LINQ code:
for (int i = 0; i < 10000; i++)
isInGroup = lst1.Cast<MyLinqTestClass1>().Any(item => item.Name == "9999");
Took 4944ms to do 1000000000 compares with LINQ.
I guess its possible to optimize the LINQ code but the thought was that its easily to get really slow LINQ code and given that it shouldn't be used. Given that LINQ is slow then it would also follow that PLINQ is slow and NHibernate LINQ would be slow so any kind on LINQ statement should not be used.
Has anyone else found that LINQ is slow that the wished they never used it or is would we be making a too general concussion based on benchmarks like this?
Should Linq be avoided because its slow?
No. It should be avoided if it is not fast enough. Slow and not fast enough are not at all the same thing!
Slow is irrelevant to your customers, your management and your stakeholders. Not fast enough is extremely relevant. Never measure how fast something is; that tells you nothing that you can use to base a business decision on. Measure how close to being acceptable to the customer it is. If it is acceptable then stop spending money on making it faster; it's already good enough.
Performance optimization is expensive. Writing code so that it can be read and maintained by others is expensive. Those goals are frequently in opposition to each other, so in order to spend your stakeholder's money responsibly you've got to ensure that you're only spending valuable time and effort doing performance optimizations on things that are not fast enough.
You've found an artificial, unrealistic benchmark situation where LINQ code is slower than some other way of writing the code. I assure you that your customers care not a bit about the speed of your unrealistic benchmark. They only care if the program you're shipping to them is too slow for them. And I assure you, your management cares not a bit about that (if they're competent); they care about how much money you're spending needlessly to make stuff that is fast enough unnoticably faster, and making the code more expensive to read, understand, and maintain in the process.
这篇关于LINQ应该尽量避免，因为它是慢？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
