C#'s LINQ is probably super slow damn it makes some easy and readable code

Or is it? 🤔
Actually, is it really slow?

It used to be super slow, but now it's as reasonably optimised as it's going to be, and for most queries it's fine.

Of course, you'll get the odd person who pulls some convoluted query out their arse to prove how slow it is, but that's not day to day use.

Besides, code readability matters way more than performance in almost all real world use.

@iiii @devnulli it creates a bunch of Enumerator objects, which live on the heap and so the garbage collector has to clean up.

If you're using arrays it would be a lot more efficient to use a regular for loop I think. But it would be a lot less readable of course.

For what I'm doing right now (plotting data for testing purposes) it's completely fine, I don't care if it takes 7 ms longer, but I can imagine that there use cases where linq isn't the right tool for the job.

@LotsOfCaffeine oh, I've assumed it was about LINQ with SQL. Haven't thought about regular arrays. For that it's obvious that it depends on the use case.

@AlmondSauce really depends on the use case I would say
Like if you're making a game you probably don't want any LINQ in your game loop.

@LotsOfCaffeine Sure, but game loops are a reasonably niche case where aggressive optimisation really matters.

If you need optimized in-memory data, then your first choice probably wouldn't be the standard library anyways, because EVERY stdlib is built to cover a wide range of use cases, not just high-perf data ops. You NEED a hi-perf library.

But for SQL, allocation on the heap will be less than 1% of the operation. Network wait and database-number-crunching will make up 99.9999% of time consumed.

For what it is, LINQ is fine and performs well.

@AlgoRythm never used it with a database before

It's just neat to filter the huge dump of test results I need to visualize