[btilly]

Any time you see toy benchmarks, ask yourself what was left out. The potential performance issue with LINQ comes when you are accessing database data over a connection with non-trivial latency. Then it is easy to wind up accidentally issuing large numbers of queries, with a lot of round trips, that winds up being slow and unnecessarily hard on the database.

LINQ is hardly unusual in having this risk. It is an easy mistake to make in many environments with many toolsets, and it is not particularly hard to avoid it with LINQ. But the toy benchmark doesn't address it. And the article makes fun of a software architect who has likely had bad experiences with developers messing up on this.

[sparky]

True for LINQ to SQL, not so much for LINQ to Objects as evaluated in the benchmarks. Of course, one toy benchmark over 1k objects doesn't fully characterize its performance, but at least we don't have to worry about the database latency free variable.

[WorkerBee]

accessing database data over a connection with non-trivial latency. ... But the toy benchmark doesn't address it

I disagree entirely. I know when I'm using LINQ to SQL, and when I'm using LINQ to objects. My experience is that LINQ to objects is more common and very useful. He's using larger data volumes than I generally am, so there's absolutely nothing "toy" about it.

[btilly]

Toy benchmarks frequently use large data volumes. That is easy to do. What is harder to do in a benchmark is providing realistically complex logic to go with those volumes. Many systems work well on the simple cases, but have bad edge cases that can get tickled by a more complex problem.

[WorkerBee]

But the logic that I have successfully used LINQ on:

- operates on lists of objects, not database queries.

- operates on small quantities of data. It doesn't matter if there are only five items in a list. If you have to filter them, you have to filter them

- is not that complex.

We use foreaches as well, or a combination. LINQ is great for automating simple things, e.g. turn a loop to find an item into a .FirstOrDefault(x => x.SomeCondition). It would be interesting to see if, as our grasp of LINQ improves, we run into any of these supposed corner cases. But it hasn't happened yet.