Menu
Possible Duplicate:
Should LINQ be avoided because it's slow?
I love LINQ. As I read in another post today “it's the best thing since sliced bread” and I totally agree. But at the company I work everyone else seems to hate LINQ.
A few weeks ago I was using ReSharper for the first time and while I was coding ReSharper suddenly told me my foreach-loop could be converted into a LINQ expression. This was like magic to me and I showed my colleague. Much to my suprise he said “I wish it would work the other way around and turn LINQ into loops. That would be much faster!”
So is LINQ-to-Objects really so slow? I tried out myself. When I run the following sample a few times I get Elapsed Ticks around 350.
Stopwatch sw = new Stopwatch();
List<Person> personList = new List<Person>();
for (int i = 0; i < 5000; i++)
{
Person p = new Person() {ID = i};
personList.Add(p);
}
sw.Start();
Person searchPerson = null;
foreach (Person person in personList)
{
if (person.ID == 4321)
{
searchPerson = person;
break;
}
}
sw.Stop();
Console.WriteLine(sw.ElapsedTicks);
If I change the loop to a LINQ-Query (Resharper will do that for me) I get ElapsedTicks around 900. More than twice as much as with the loop.
Person searchPerson = personList.FirstOrDefault(person => person.ID == 4321);
As is seems LINQ is indeed slower and if you use it a lot this could be an issue. And at our company we have lots of data. So is it the right decision to avoid LINQ or are we doing something wrong?
316
It is slightly slower LINQ syntax is typically less efficient than a foreach loop. It's good to be aware of any performance tradeoff that might occur when you use LINQ to improve the readability of your code. And if you'd like to measure the performance difference, you can use a tool like BenchmarkDotNet to do so.
Most of the times, LINQ will be a bit slower because it introduces overhead. Do not use LINQ if you care much about performance. Use LINQ because you want shorter better readable and maintainable code. So your experience is that LINQ is faster and makes code harder to read and to maintain?
Both yields the same result because query expressions are translated into their lambda expressions before they're compiled. So performance-wise, there's no difference whatsoever between the two.
A stored procedure is the best way for writing complex queries as compared to LINQ. Deploying a LINQ based application is much easy and simple as compared to stored procedures based.
Yes, it's slower. However, a portion of that delay is a one-time initialisation delay, rather than a per-iteration delay. The percentage difference is quite a bit lower on a 100k iteration loop.
The point to take away is that developer time is significantly more expensive than a small performance loss in your code, unless the customer is calling you up to complain about performance problems. Writing readable and maintainable code is much more important than micro-optimising your code.
As Eric Lippert pointed out so perfectly, LINQ should only be avoided if it's not fast enough.
157
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
