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

  • 1
    Or is it? 🤔
    Actually, is it really slow?
  • 7
    it's not faster or slower than other things, problem is, you can make extremely complex operations by writing simple statements.

    its superslow when ppl dont want to think about what happens behind the scenes, do wrong access paths, toList() and what not
  • 1
    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.
  • 0
    @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.
  • 0
    @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.
  • 0
    @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.
  • 1
    @LotsOfCaffeine Sure, but game loops are a reasonably niche case where aggressive optimisation really matters.
  • 3
    you are right, i wouldnt build it in a game loop. and yes, the indirections of the lambdas and the enumerators on the heap, they cost.

    but.. in my case of enterprise software, i would still use LINQ, for many reasons, the biggest reason being maintanability, readability, and especially the fact that LINQ is a validated, unit tested, structured access mechanism that we would otherwise have to create, maintain, unit test, on our own..

    also im not experienced with SQL and LINQ, but we use it on internal model objects and stuff, so i dont know but in sql it should be more equal
  • 0
    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.
  • 0
    @AlgoRythm never used it with a database before

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