4 ms·
There's one BIG problem with LINQ. I'll agree that the syntax is marvelous, a game changer. The problem is performance. It's gotten slightly better over the ye
by throwawasiudy 10y ago
There's one BIG problem with LINQ. I'll agree that the syntax is marvelous, a game changer. The problem is performance.
It's gotten slightly better over the years but compared to an ORM with less abstraction like Hibernate it's still dog slow. Every MS project I've worked on was mostly LINQ...then a folder called "dirty SQL" for the heavy stuff.
I'm not sure if it's due to the highly abstracted nature or just not making performance a priority but in my experience sane Hibernate queries are about 1/2 the speed of native SQL and LINQ is closer to 1/50.
I hope and pray they can make the performance at least within an order of magnitude of raw SQL or even Hibernate so I can say goodbye to SQL forever.
- NicoJuicy 10y agoUse LINQ for development and production, when you need performance use Dapper. It shouldn' be too hard if you follow the DDD pattern. You can always use DataContext.Database.SQL(query) ofc
- throwawasiudy 10y ago> You can always use DataContext.Database.SQL(query) ofc that's pretty much our MO :) . Never used Dapper, how reliable is it? I ask because we use StackExchanges' Redis client for C# and it mysteriously crashes even after untold hours of debugging
- NicoJuicy 10y agoActually, haven't had any issues with it. So, it's safe to say that i find it very stable.
- deleted 10y ago[deleted]
- WorldMaker 10y agoAt a previous job I worked hard to prove that I could make LINQ queries perform within small tolerance of the window of hand-written SQL alternatives. Performance tuning LINQ is a science that I think escapes far too many people. Often it seemed to simply be mistakes that they wouldn't make in hand-written SQL, but they were writing LINQ too much like C# instead of enough like SQL.