Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
iiii175512dOr is it? 🤔
Actually, is it really slow?
devnulli51212dit'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
AlmondSauce988312dIt 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.
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
AlgoRythm4763212dIf 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.