Wish I could give you 2 thumbs up. One for detailing exactly how to do it, the other for delving into the performance difference so I already know what to expect. Well done sir.
Thanks for this new piece of information it will be really helpful and i read about in your newsletter as well on Sunday. Just a request from a beginner can you make videos for beginners as well like from basic (more kind of a tutorial)
Is DbContext creation inside a benchmark so insignificant that it is ok have it there? Not sure how much of internal logic is reused with new operator in contrast with pooling contexts.
Is it better to collect related compiled queries in a repository related to their entity then inject the repository when needed or place them in DbContext?
Why are you create DbContext inside benchmark method? In that case you also measure DbContext creation and connection opening instead of measuring just difference between compiled and usual version.
You’ve talked briefly about the compiled query caching, but if I’m right, that means if I ran the “NotCompiled” version of the query more than once in my application lifetime, the difference in performance would be significantly less, correct ?
thanks a lot Milan for that awesome video 👍. how to create compiled queries in Clean Architecture and I can only access IApplicationDbContext in the Application layer and not ApplicationDbContext which in the Infrastructure layer?
I enjoyed this video, thank you. As someone who moved away from EF back when it was EF5 to ADO (for performance reasons), I'm now exploring moving back to EF Core as the team has done a great job with performance over the years. ADO is faster, but it's less of a different and EF has lots of benfefits. I have one question though, and wondered if I'm missing something obvious. When you wrote the Async Compiled Query, why did you use FirstOrDefault rather than FirstOrDefaultAsync?
Because there's nothing _magically different_ between FirstOrDefault and FirstOrDefaultAsync in terms of the generated SQL, when you think about it. All the Async version does is to asynchronously await the task completion, while the other one blocks. But they generate the same SQL. So in the compiled query, you write the LINQ in terms of the expression you want to run with EF - and the compilation takes care of generating a state-machine to be able to run it asynchronously. At least this is my understanding of how it all works. 😅
My question would be : -What happens if the dataset changes in the background? Is there some security mechanism that recompiles my query if this happens?
What is better in terms of performance for simple select queries with few filters (2 props lets say). Compiled Async Queries ? Or using ef methods like SqlQuery, FromSql ?
How much does the construction of the DbContext cost. That is a common cost in both tests, if that is significant then the performance improvement is better than what you have stated. OTH if its not significant it might have been worth mentioning to keep that clear Other considerations are application start time. Compiling a single simple query may not be that significant but what about a system with a large number of complex queries. Using some lazy approach that compiles and caches the query on demand IMO wouldn't' be hard though.
Can I use conditional inside the CompileQuery? Like build the query based on the input for exemple IQueryable query = _context.Set().OrderByDescending(x=> x.Date); if (id.HasValue) query = query.Where(x => x.Id == id.Value); return query; Or it needs to be a more objective query, like the examples given
![Lp. Точка Невозврата #3 ВОЛШЕБНАЯ ФРАЗА [Личное Измерение] • Майнкрафт](http://i.ytimg.com/vi/BilZhLRtLUE/mqdefault.jpg)
Want to master Clean Architecture? Go here: bit.ly/3PupkOJ
Want to unlock Modular Monoliths? Go here: bit.ly/3SXlzSt
Hi...i get error when returning Task...please help me
Wish I could give you 2 thumbs up. One for detailing exactly how to do it, the other for delving into the performance difference so I already know what to expect. Well done sir.
Wow, thanks!
just make another account bro so you can give him another thumbs up.
Axaxaxa Preview 😮 TOP content bro you are awesome 💯!
Thanks a lot!
Love your informative videos man. Much appreciated
I appreciate that!
Hi, such a nice and easy way to explain all what you know about EF and how it works! Thanks a lot.
Glad it was helpful!
Thanks for sharing this bit of optimization
You bet!
Awesome content! You're the best Milan.
I appreciate that!
What about EF queries vs calling stored procedures
You're welcome to make that benchmark 😁
Might as well just go back to writing sql
Thanks for this new piece of information it will be really helpful and i read about in your newsletter as well on Sunday. Just a request from a beginner can you make videos for beginners as well like from basic (more kind of a tutorial)
I can't promise that I'll make anything truly beginner friendly soon, since I want to talk about more advanced topics
Is DbContext creation inside a benchmark so insignificant that it is ok have it there? Not sure how much of internal logic is reused with new operator in contrast with pooling contexts.
DbContext isn't thread safe, so my concern was not running into threading issue during benchmark.
Very informative, as usual. Can we expect 'EF: zero to hero' series?
Possibly! Maybe in the form of a course 🤔
Hello, could you describe why you are using context.Set , and not using context.entity?
I just prefer it over having to write the DbSets as properties
koju web kameru i mikrofon koristis?
Kamera: Poco X3 Pro (telefon)
Mikrofon: Redragon GM300
@@MilanJovanovicTech ne strimujes sa telefona na komp preko app (Iriun npr) nego sve snimis na telefon pa posle prebacis i editujes?
@@markokraljevic1590 Tako je. Neuporedivo je bolji kvalitet sa telefona. Iriun koristim samo da podesim kameru na pocetku, doduse.
@@MilanJovanovicTech nisi radio live streamove do sad, niti planiras? jel bi i za to koristio telefon ili nesto drugo?
Is it better to collect related compiled queries in a repository related to their entity then inject the repository when needed or place them in DbContext?
Placing them where they're used is probably the best practice
@@MilanJovanovicTech what if they are a common use compiled queries by some commands or queries?
@@Tamer_Ali Extension methods, and since the class is static you can place them there 🤔
Why are you create DbContext inside benchmark method?
In that case you also measure DbContext creation and connection opening instead of measuring just difference between compiled and usual version.
More realistic use case
I don't get it work with table-joins (Linq: include() an List-Property in DbSet, which contains items from 2nd table).
Hmm?
How can implement order by with EF.CompileAsyncQuery
It should work just fine. Does it not?
@@MilanJovanovicTech it works. On result we need to add order by.
Nice video. What about an IAsyncEnumerable?
Async = more throughput, not necessarily faster queries
You’ve talked briefly about the compiled query caching, but if I’m right, that means if I ran the “NotCompiled” version of the query more than once in my application lifetime, the difference in performance would be significantly less, correct ?
No, the difference in performance is what you see in the benchmark. Since the benchmark is effectively the application lifetime.
thanks a lot Milan for that awesome video 👍.
how to create compiled queries in Clean Architecture and I can only access IApplicationDbContext in the Application layer and not ApplicationDbContext which in the Infrastructure layer?
Hide it inside a repository or the DbContext
@@MilanJovanovicTech if I hide it inside DbContext I won't be able to access and call it in a command or a query when I need.
I enjoyed this video, thank you. As someone who moved away from EF back when it was EF5 to ADO (for performance reasons), I'm now exploring moving back to EF Core as the team has done a great job with performance over the years. ADO is faster, but it's less of a different and EF has lots of benfefits. I have one question though, and wondered if I'm missing something obvious. When you wrote the Async Compiled Query, why did you use FirstOrDefault rather than FirstOrDefaultAsync?
Because there's nothing _magically different_ between FirstOrDefault and FirstOrDefaultAsync in terms of the generated SQL, when you think about it. All the Async version does is to asynchronously await the task completion, while the other one blocks. But they generate the same SQL.
So in the compiled query, you write the LINQ in terms of the expression you want to run with EF - and the compilation takes care of generating a state-machine to be able to run it asynchronously.
At least this is my understanding of how it all works. 😅
@@MilanJovanovicTech Of course! Makes total sense, I think I was missing the obvious. Thanks for taking the time to respond! 👍
My question would be :
-What happens if the dataset changes in the background? Is there some security mechanism that recompiles my query if this happens?
Nothing you can do about it, honestly. I wouldn't even give it a thought
@@MilanJovanovicTech Is that means: the real usecase cenario is if i use on datasets ,they not frequently changes..isnt it ?
Thanks!!
You bet!
What is better in terms of performance for simple select queries with few filters (2 props lets say). Compiled Async Queries ? Or using ef methods like SqlQuery, FromSql ?
Do a benchmark? 😅
My guess is that SQL will be slightly faster - but your needs will dictate what you want to use
Very informative
Glad you liked it!
How much does the construction of the DbContext cost. That is a common cost in both tests, if that is significant then the performance improvement is better than what you have stated. OTH if its not significant it might have been worth mentioning to keep that clear
Other considerations are application start time. Compiling a single simple query may not be that significant but what about a system with a large number of complex queries. Using some lazy approach that compiles and caches the query on demand IMO wouldn't' be hard though.
I think creation of the DbContext is insignificant enough to not affect the querying, so I just left it as is.
How can I do a compiled async query with dotnet framework 4.5.2 ?
Don't know, haven't used .NET Framework in years
@@MilanJovanovicTech ok, I'm using only .net core until now. Kkk thank you !
another an excellent insight. Thank you. if you could do some thing related to User Impersonation via Jwt token.
I really hate user impersonation 🤣
@@MilanJovanovicTech understanding the concept with an example will be good :) with in gatherly app :)
its a no than we wont be seeing anything about user impersonation :) :).
Is it possible to use CompileAsyncQuery for Add and Update? Or only for Get ?
I don't think so - at least it doesn't make sense to me. But I didn't try it.
💯💯💯
✅💪
Can I use conditional inside the CompileQuery? Like build the query based on the input for exemple
IQueryable query = _context.Set().OrderByDescending(x=> x.Date);
if (id.HasValue)
query = query.Where(x => x.Id == id.Value);
return query;
Or it needs to be a more objective query, like the examples given
Anything that's a valid LINQ expression can be compiled - so no, you can't do something like you proposed there.
@@MilanJovanovicTech thank you Very much for the anwser!
I suspected that was the case, still can be useaful in hot paths of static queries
👋