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