Lovely article Beautus! As other commenters mention I also remember this thrill and power when witnessed at first. It is truly an amazing feeling and I share your excitement with JSX. It is great to hear you have bound with feature of a language such as LINQ as that will guide you to discover other amazing features like maybe the newest pattern matching in switch clauses? Which again might lead you to a totally different but .NET language as F#.
Keep on mind, LINQ syntax gives you range variables which you do not have in the lambda function syntax. The LINQ syntax eventually ends up “compiled” into lambda syntax, i.e. just a bunch of methods, read a ref explanation here: stackoverflow.com/a/20573973
If you are interested to understand the fantastic IEnumerable “driver” of the LINQ and how to literally reimplement then google for EduLINQ by Jon Skeet. Harnessing the yield keyword with iterators and generators is what made love C# even more. Afterwords you can google how LINQtoEntities works (thats the one you use with _context), hint/spoiler its an amazing compiler that helps it with “translation” into SQL with a ton of expression visitor pattern implementations composed to build a compiler pipeline... uh :-)
Also a side note on async as I am very allergic to that topic :-), it will make your code slower but it will take care of memory better in longer (scale up scenario) shots. It is not a silver bullet and it has nothing to do with increasing performance at all (only maybe decreasing it). Google Stephen Cleary and his blog for more info.
I just read through the stackoverflow link and I'm stunned. But through that revelation, I had to wonder how performant a Lambda api would fare up against 100 million rows of data as opposed to using a raw query
Hey. Your thoughts stream to right questions! Actually EF is a lot slower than raw cons (or Dapper queries), for a test in the following link 10x to 15x times, but the test is not a real world scenario, i.e. do not infere that Dapper or ADO is better, as speed is just one treat. Read more about the test: exceptionnotfound.net/dapper-vs-en...
Also EF has to cache your lambdas after translating them for the first time into SQL strings. Also note some queries can not be cached due to their dynamic construction (you can build up a query with multiple C# statements) such as any query using a .Where(x => someNumbers.Contains(x.Id)), as the SQL “where in” (it is actually a ton of OR statements if you look into SQL) part is actually calculated each time.
Using EF is certainly not a question of speed.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Lovely article Beautus! As other commenters mention I also remember this thrill and power when witnessed at first. It is truly an amazing feeling and I share your excitement with JSX. It is great to hear you have bound with feature of a language such as LINQ as that will guide you to discover other amazing features like maybe the newest pattern matching in switch clauses? Which again might lead you to a totally different but .NET language as F#.
Keep on mind, LINQ syntax gives you range variables which you do not have in the lambda function syntax. The LINQ syntax eventually ends up “compiled” into lambda syntax, i.e. just a bunch of methods, read a ref explanation here: stackoverflow.com/a/20573973
If you are interested to understand the fantastic IEnumerable “driver” of the LINQ and how to literally reimplement then google for EduLINQ by Jon Skeet. Harnessing the yield keyword with iterators and generators is what made love C# even more. Afterwords you can google how LINQtoEntities works (thats the one you use with _context), hint/spoiler its an amazing compiler that helps it with “translation” into SQL with a ton of expression visitor pattern implementations composed to build a compiler pipeline... uh :-)
Also a side note on async as I am very allergic to that topic :-), it will make your code slower but it will take care of memory better in longer (scale up scenario) shots. It is not a silver bullet and it has nothing to do with increasing performance at all (only maybe decreasing it). Google Stephen Cleary and his blog for more info.
Cheers,
V.
I just read through the stackoverflow link and I'm stunned. But through that revelation, I had to wonder how performant a Lambda api would fare up against 100 million rows of data as opposed to using a raw query
Hey. Your thoughts stream to right questions! Actually EF is a lot slower than raw cons (or Dapper queries), for a test in the following link 10x to 15x times, but the test is not a real world scenario, i.e. do not infere that Dapper or ADO is better, as speed is just one treat. Read more about the test: exceptionnotfound.net/dapper-vs-en...
Also EF has to cache your lambdas after translating them for the first time into SQL strings. Also note some queries can not be cached due to their dynamic construction (you can build up a query with multiple C# statements) such as any query using a .Where(x => someNumbers.Contains(x.Id)), as the SQL “where in” (it is actually a ton of OR statements if you look into SQL) part is actually calculated each time.
Using EF is certainly not a question of speed.