Venflow VS Entity Framework 6

Since you hung around until the very end, I’m assuming you have some interest in Venflow. Therefore, if you haven’t yet, check out the README over on GitHub to learn even more about it.

I am currently still hard at work on my ORM [Venflow](https://github.com/TwentyFourMinutes/Venflow), which always gives me new challenges wherever I look, however the learning experience is huge. Additionally I am giving it the final touches for the first non-pre-release version which I am quite happy about, since I am working on it for roughly half a year. If you are interested about it you can either read the last [reddit post](https://www.reddit.com/r/csharp/comments/j5e8w2/i_want_to_share_my_biggest_project_yet_which_i/) I made or ask me right here :).

If I understood your post correctly, you are essentially trying to create your own ORM. I also want to add that I started to create an ORM on my own a few months back and it has been a pretty interesting experience so far. However there should be one big thing that you should consider.

Additionally, an individual context will also cache the actual sql being performed and their docs go over the caching it does here regarding that.

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 contention. Heavy in our case meant that for a single page build of one of this app's "hot path" pages, this lock would be taken a few hundred thousand times. We weren't the first to discover this:

https://github.com/dotnet/ef6/issues/1500

What some other people in my team were struggling with for about two weeks was resolved in a single day thanks to me goofing off and reading HN. (We ultimately used a fork of EF6 that didn't suffer from this issue to solve our problem)