Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?


migration rejected from Feb 26 '15 at 13:10

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as primarily opinion-based by gbjbaanb, gnat, MainMa, MichaelT, Bart van Ingen Schenau Feb 26 '15 at 13:10

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

This appears as though it would lead to great debate – Woot4Moo Aug 27 '11 at 23:56
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
FOr those of you who think performance isn't important, I don;t want you anywhere near my ENterprise database. It is critical for databases and they need to bedesigned with this in mind. A littel slow with 10,000 records is unsualble at 10,000,000 records and acomplete rewrite of teh whoel system when you started with something that performs badly is not a fun experience. Espcailly when it's in production and you have to fix it NOW. And frankly the code is not more readable if you actually bother to learn SQl. – HLGEM Dec 21 '11 at 23:14

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.

AMEN brother!!!!! +100 for that. – Steven Aug 28 '11 at 3:19
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, but this is a 'tutorial' if you can call it that: – gbjbaanb Aug 30 '11 at 10:55
Editing answer to put small in context – Preet Sangha Sep 6 '11 at 22:20

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).

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<>? Perhaps now lambdas do get inlined in some scenarios? – ebyrob Oct 26 '13 at 13:49

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?

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

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.


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.


Readability for what, and readability for whom?

Consider LINQ for SQL databases. I know SQL, you know SQL, everyone knows SQL. So if you did some SELECT COUNT (...) stuff, we'd all know what you just did.

Properly written SQL is plenty readable (not counting the select with a subselect with a subselect with some... vendor specific useful options as they're known. (Our vendor at that point is likely Lucifer.))

Now consider it for some list of some description. Obviously going to be a massive help. I mean, Java got something similar-ish for Java 8, so it's not like other languages aren't seeing the use-case for them.

So like all other intelligent questions the answer boils down to "it depends".

This does not add much over earlier answers, especially if you conclude with it depends. – Jan Doggen Feb 26 '15 at 8:16

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