Should LINQ be avoided because it's slow? [closed]

Answer 1

As you demonstrated, it is possible to write non-LINQ code that performs better than LINQ code. But the reverse is also possible. Given the maintenance advantage that LINQ can provide, you might consider defaulting to LINQ as it is unlikely you will run into any performance bottlenecks that can be attributed to LINQ.

That said, there are some scenarios where LINQ just won't work. For example, if you are importing a ton of data, you might find that the act of executing individual inserts is slower than sending the data to SQL Server in batches of XML. In this example, it's not that the LINQ insert is faster than the non-LINQ insert, rather it's not prodent to execute individual SQL inserts for bulk data imports.

Answer 2

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.

Answer 3

The problem with this sort of comparison, is that its meaningless in the abstract.

One could beat either of those if one got to start by hashing the MyLinqTestClass1 objects by their Name property. In between those if one could sort them by Name and later do a binary search. Indeed, we don't need to store the MyLinqTestClass1 objects for that, we just need to store the names.

Memory size a problem? Maybe store the names in a DAWG structure, combine suffices and then use that for this check?

Does the extra overhead in setting these data structures up make any sense? It's impossible to tell.

A further matter is a different problem with the concept of LINQ, which is its name. It's great for marketing purposes for MS to be able to say "here's a bunch of cool new stuff that works together" but less good when it comes to people combining stuff together when they are doing the sort of analysis where they should be pulling them apart. You've to a call to Any that basically implements the filter-on-enumerable pattern common in .NET2.0 days (and not unknown with .NET1.1 though it being more awkward to write meant it was only used where its efficiency benefits in certain cases really mattered), you've got lambda expressions and you've got query trees all bunged together in one concept. Which is the slow one?

I'd bet the answer here is the lambda and not the use of Any, but I wouldn't bet a large amount (e.g. the success of a project), I'd test and be sure. Meanwhile, the way lambda expressions work with IQueryable can make for particularly efficient code that it would be extremely difficult to write with equivalent efficiency without the use of lambdas.

Do we not get to be efficient when LINQ is good at efficiency because it failed an artificial benchmark? I don't think so.

Use LINQ where it makes sense.

In bottleneck conditions, then move away or to LINQ despite it seeming appropriate or inappropriate as an optimisation. Don't write hard to understand code first go, as you'll just make real optimisation harder.

Answer 4

Here's an interesting observation, since you mention nHibernate being slow as a consequence of LINQ being slow. If you're doing LINQ to SQL (or the nHibernate equivalent), then your LINQ code translates to an EXISTS query on the SQL server where as your loop code must first fetch all rows, then iterate over them. Now, you could easily write such a test so that the loop code reads all the data once (single DB lookup) for all 10K runs but the LINQ code actually performs 10K SQL queries. That's probably going to show a big speed advantage for the loop-version which doesn't exist in reality. In reality a single EXISTS query is going to outperform the table scan and loop every time -- even if you don't have an index on the column being queried (which you probably would if this query is done very often).

I'm not saying that it is the case with your test -- we don't have enough code to see -- but it could be. It could also be that there really is a performance difference with LINQ to Objects, but that may not translate to LINQ to SQL at all. You need to know what you're measuring and how applicable it is to your real world needs.

Answer 5

I would rather say you should avoid trying too hard to write most efficient code, except it is mandatory.

Answer 6

Is LINQ a real-world bottleneck (either effecting the overall or perceived performance of the application)?

Will your application be performing this operation on 1,000,000,000+ records in the real-world? If so--then you might want to consider alternatives--if not then it's like saying "we can't buy this family sedan because it doesn't drive well at 180+ MPH".

If it's "just slow" then that's not a very good reason... by that reasoning you should be writing everything in asm/C/C++, and C# should be off the table for being "too slow".