@realnamexd7838
The problem is in the SqlClient 5.1 version, which is the latest LTS version and therefore the one used by EFCore, it is possible to solve this problem by switching to 5.2
@Michal8181
Hi Nick This is only for SQLServer. Sqlite and postgresql is not affected.
@sebastiandorsch2865
Hi Nick, I always enjoy your videos. Thanks for that. In this case I feel, that some things you say in this video are a bit besides the point. At 2:57 you say one would expect the async-version to be faster than the sync version. I never expected that. in the end, the async version of a call does the same work as the the sync version, but with added complexity. Of course, it should not take almost twice as long as the sync version. So you are right to point out this issue. And I agree, it is a problem that people need to know about, until it hopefully is fixed at some point. But it is not a general issue of async programming. sync and asyn is not primarily about speed. Its not called fast and slow version. Its call sync and async version. And therefore I expect the async version to allow my app to do other things, while the async call is in progress. The sync version will not allow for that. So, if my app needs to stay responsive at all times, I might even accept the much longer runtime in this special case for the added benefit of responsiveness.
@obiwanjacobi
Async-await is not for performance. It is for scalability. Think: doing something else while the IO is on the way. (Glad you came to that same conclusion in the end - I think you could have given that a little more emphasis).
@IllidanS4
If someone thinks that an async version of a method should have better performance than a sync one, they simply don't understand how it works and what it's for.
@desertfish74
Using the Firefox profiler UI to interact with this is very clever
@ryankueter9488
The best way to learn multithreading is to have student programmers manually multithread applications first, the way it was done in the past. Then you begin to see how many scenarios in which multithreading is unnecessary and could lead to more problems than it solves. For example, if a line of code executes instantaneously (e.g., a simple mathematical calculation) and does not affect the performance of the application, it's not necessary to create an (async await) state machine to handle that operation. For longer running processes or processes that make external calls, like database calls, that could hang-up your current thread, then yes you do want to multi-thread that process. With that said, the async await pattern is still handy and probably overused.
@KingOfBlades27
You ask me it is pretty clear to use async always unless you know that for some specific reason sync works better. 99/100 times you are correct choosing async.
@MahmoudBakkar
This is an edge-case, and usually edge cases are tricky to handle. Depends on the actual problem you're trying to solve. Agree with your conclusion and other people here. I'd design those edge cases with configs to run it sync or async, where it can be toggled on or off anytime.
@michaelschneider603
Using async is about to avoid blocking platform threads, of which there are only a handful on the machine where you're application is running, and thus about scalability / level of concurrency, not about making individual method calls faster. Obviously, the call times you measured are primarily determined by the underlying database request, which is the same in both cases, and the async variant will be more complex than the sync variant and there may (and hopefully will) be additional work being done asynchronously by your application in the meanwhile. Which means that it is to be expected that the individual async call will not be faster and probably slower than the individual sync call. But when a single REST-API request of your application runs in a single thread, then using sync database access will limit the number of parallel requests an application service instance can handle to the size of the thread pool of the .NET runtime, which itself is upper bounded by the number of platform threads available on the machine / operating system. There will be no such strict limitation for async database calls and thus no such strict limitation for how many parallel requests you application can handle. Of course, other resources such as memory will still be a limiting factor, but that's a different story.
@nenadmarkovic7770
Danke!
@bloodjam30050
I've run into this issue before when we had some archiving server which was used to bring up historic data for a bimonthly audit. They need 100k records (which is a small dataset for this particular company) with a large variable page size on the SQL server. You could make an optimization like not using varchar(max) as well. But in this instance we did change to synchronous and because the only responsibility of this service is 3 routes which spit out 100k rows the performance benefits of making the CPU run hot for quicker retrieval outweighed the scaling issues associated with not using async await. You could argue that a lot of micro services with a simple retrieval responsibility would be better served in synchronous run time while this big exists
@nathankirsten6555
Ran into this same problem a year ago and found the GitHub issue you are referring to. Changing the slow performing async method to sync solved the issue.
@alexbarac
Not sure if this is comparing sync vs async or promoting the new package :( I'd rather have a comparison between DbContext AddAsync and DbContext Add, or when to return the Task and when to return the value in an Async method, those are concepts that can confuse a lot of programmers that do not have enough experience with Async/Await and EF Contexts.
@delphiguy23
Interesting. Question tho, is this specific with EFC+MsSQL? Does this also occur with EFC+Postgres? Etc…. Also what if I use Dapper instead? Does the same issue exists?
@Pretence01
Async is about scalability
@haxi52
As with anything related to performance. You should write it so it is easy to understand and/or consistent with the existing code base. If you are using async everywhere, then keep doing that. Until you run into a perf issue, then run benchmarks and optimize till the performance is satisfactory.
@standleypeter545
Not much context given to this video. This is not valid for postgresql. Tested it and async await twice of the performance of sync in posgres. Memory allocation is alnost the same. Below is the result: Time taken to fetch data sync: 00:00:04.1417377 ms Total memory used: 2035098592 bytes Retrieved 1000000 records Time taken to fetch data async: 00:00:02.7830356 ms Total memory used: 2035709168 bytes Retrieved 1000000 records
@Maestrou-jb1rq
This memory bug is really a big one and I'm surprised that Microsoft doesn't fixed it for 5 year's. That's crazy
@oussama7132