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?
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
migration rejected from stackoverflow.com 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.
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:
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.
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:
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).
The special thing about LINQ is that evaluations are lazy. It means that:
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?
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".