ef6

Well, as soon as you adopt a library it becomes your problem if something is happening. I tend to simplify things as much as possible and using my own code. Doing PoC's to see if i can adopt a certain "thing". So my solution for being "powerlessness" is owning the code i use and therefore I know what it does. I use tools a lot, but also because of that, I'm able to fix issues fast and mostly the error is from my end. For example, i had some slow query generation in EF a couple of years ago and this led to the EF team implementing a Like operator. - https://github.com/dotnet/ef6/issues/115 ( I actually had to debug the library and give a reasonable explanation to the team. They found a solution, that they already considered. Which i think is pretty awesome of them! I use the like operator a lot by now)

Every so often, posts from Bruce Dawson's blog get posted here - one such post was about using Event Tracing for Windows to diagnose an issue with an NTFS lock being held causing 63 cores to idle while 1 does all the work. https://randomascii.wordpress.com/2019/10/20/63-cores-blocke... A few months later, some other people in my team were struggling to diagnose an issue in production where a legacy webapp was struggling to scale up and fully use all 64 cores of the server we needed it to run on. I stepped in to help and remembered that post I'd seen on HN. We used ETW (through Windows Performance Recorder and Windows Performance Analyzer) to profile our app and I looked into the Wait Analysis. Turns out that Entity Framework 6 uses a ReaderWriterLockSlim to guard a cache, and that particular lock performs extremely poorly under heavy cont

.ToList() executes the query. If you're trying to lazy load after that, you will get significant performance issues. Otherwise, I've created an erp+e-commerce on EF and didn't encounter much issues. One time, i had an performance issue case and detailed the issue on the nuget repo. Next release had a workaround. https://github.com/dotnet/ef6/issues/115