Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

We are considering using LINQ (to Objects) in our (commercial grade) projects where performance may be an issue. I have heard it may impact performance, but then the code is so much more readable and maintainable. Is this trade-off really worth it?

share|improve this question

migrated from stackoverflow.com Aug 27 '11 at 23:58

This question came from our site for professional and enthusiast programmers.

1  
This appears as though it would lead to great debate –  Woot4Moo Aug 27 '11 at 23:56
3  
I can understand LINQ to SQL or LINQ to Entities being slower than raw ADO.NET, but why do you think LINQ to Objects is slow? compared to what? –  Max Toro Aug 28 '11 at 0:22
    
Performance does not matter as long as you don't have a bottleneck somewhere. Write the code first with readability in mind and the optimize where it really matters. –  Falcon Aug 28 '11 at 7:44
    
Also, you have already chosen managed code over native coding and so already looking for greater language benefit. –  Steve-o Aug 28 '11 at 12:39
    
is it really LINQ itself that's slow, or is it your custom enumerators or that you're running it over Entity Framework. –  gbjbaanb Aug 28 '11 at 14:32
show 2 more comments

5 Answers 5

I now work as a support developer. So large parts of my day are spend reading lots of others code and working out what it's doing. And why.

If there was few things I could say after deciphering code it would be that:

  • simple code is good
  • use of common code is very very good
  • cost of maintennance is more than the cost of making something fast in the main
  • comment optimisations and quirks if they're really needed.
  • less code is good, but terse code has the problem that it conflicts with the 'simple code' ideal. The line is hard to define, but in general compilers don't need terseness over simple code. So I'm demoting this to the last one in the list.

Linq offers many places to simplify and reduce code. I often refactor code (with tests mind you) to make things simpler using Linq, or in fact using other common code.

Slowness of Linq over custom code has yet to be a problem over the cost of maintenance. Besides it easier to optimise common code than custom code. If you do have a problem it may not be the use of Linq, it may just be the use of inappropriate algorithms. Linq isn't the only solution by far, and you can buy other libraries to do other work for you.

On a related note there must be reason that new technologies using the Linq paradigm (e.g. Rx) are materialising - namely that it must be good abstraction for a large set of common problems. And as we all know long term software is all about abstractions and models.

share|improve this answer
    
AMEN brother!!!!! +100 for that. –  Steven Aug 28 '11 at 3:19
3  
less code is good? I have a website full of 'golf' code you need to see that will make you change your mind. –  gbjbaanb Aug 28 '11 at 14:33
    
@gbj - sure just email me and I'll have a look –  Preet Sangha Aug 29 '11 at 19:27
    
try codegolf.com, but this is a 'tutorial' if you can call it that: perl.guru.org/scott/misc/golf.html –  gbjbaanb Aug 30 '11 at 10:55
1  
Editing answer to put small in context –  Preet Sangha Sep 6 '11 at 22:20
add comment

Yes, I use LINQ in commercial grade projects and I LOVE it - as we say down this end of the world, it's the best thing since sliced bread.

Seriously. Some very smart people have designed and built LINQ. Now I can use it to quickly query my lists of objects, or perform aggregate functions on them. Sure, some of this I could do myself in a loop, but a LINQ query is more concise and so much more expressive.

If you think your LINQ query is too slow, consider these points:

  • Is it really too slow? What is your time comparison based on? Have you timed it any other way?
  • Consider using Parallel LINQ, it is incredibly efficient at processing larger lists on multi-core machines
  • Do you need to use LINQ on such a large list, should you be retrieving less data from the data repository to begin with? Should you be using the database to do the work instead of the LINQ query?
  • Could you make some small tweaks to your data objects to enable you to write a better LINQ query than you currently have?

Frequently the perceived slowness of LINQ will not be from LINQ itself, but rather from things like a Entity Framework based Data Access Layer, where you use LINQ to query for the data and then use reflection to transform the EF objects to more lightweight DTOs - LINQ isn't slow, reflection is (especially if you are doing it on thousands of objects).

share|improve this answer
    
I am a LINQ freak, use it all the time, and I never really experienced a situation where LINQ to Objects was too slow for me (compared to LINQ to SQL and especially Entity Framework). LINQ to Objects is highly optimized and has for instance special optimization while querying arrays. –  Steven Aug 28 '11 at 3:22
    
@Steven Optimization? Is List<>.Find() faster than a simple for loop over the List<>? stackoverflow.com/questions/401482/find-vs-enumeration-on-lists Perhaps now lambdas do get inlined in some scenarios? –  ebyrob Oct 26 '13 at 13:49
add comment

The special thing about LINQ is that evaluations are lazy. It means that:

  • The computation is done only when it needs to be done,
  • If you don't know what you're doing, chances are that the same computations will be done twice, or thousand times, or ten billion times.

The first point means that in several cases, the performance of LINQ-enabled code will be higher than in the non-LINQ code. In other words, it can be an advantage to use LINQ when you know what you're doing, but want to write less code.

The second point means that inexperienced developers who don't care about learning things before writing code will notice sometimes huge performance problems. But, well, do they care about performance? Or do we care about the performance of their code?

share|improve this answer
1  
Good point. As with all new technologies, LINQ can be used wrong and in that case it can cause performance problems, but not because of LINQ but because of its abuse. –  Steven Aug 28 '11 at 3:23
add comment

I have used Linq to SQL and I can say that it is not efficient. I can appreciate code readability and simplicity just as much as the next developer, but linq to sql pounds the database. I have proven this through trace analysis. Until it is improved, I am going to continue traditional ADO.NET flow.

Code simplicity often means abstraction and assumed automation. Not always a bad thing, and sometimes a great thing. But you can't always press the "I believe" button without testing this type of thing against other methods.

share|improve this answer
add comment

We've done testing on LINQ performance before and in most cases you get less than 10% performance hit (if needed I could go look up the test results). Which in most scenarios is more than fine to deal with. There are some particular edge cases in which LINQ tends to build crazy queries and you can profile to find these.

With LINQ, you should only think about performance when you notice performance issues (in which case the problem most likely is somewhere else anyway, or you got an edge case), or when a given method with your LINQ statement is called millions of times during execution. Otherwise, spend your time on other things like improving maintainability, fixing bugs, ...

I personally wouldn't doubt to use LINQ in my code for better maintainability for the very small performance loss.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.