Years ago, we were revamping a mission-critical project with more than a 1000 database tables to a backend of .net and EF. Our rewrite was much cleaner, but sti

Years ago, we were revamping a mission-critical project with more than a 1000 database tables to a backend of .net and EF. Our rewrite was much cleaner, but still had 450 tables. We started noticing that our backend took 2 minutes after starting up to serve the first request, fast after that. It turned out EF had a stage named "view generation" which verified that data would round-trip, meaning if it goes into the DB and comes back, would stay the same. Run time was exponential on the number of tables and complexity of models. People used tricks to work around it, which was basically caching the "generated view" in a file, which could speed up the production startup, not as easy in DEV environment, our programmers still needed to wait 2 minutes after each compile. I started looking into it, and it turned out that Microsoft had open sourced EF a short time ago (long after we had started the project). While profiling, view generation took much longer, 450s, as it was a CPU-heavy process. There was a function excluded from release builds by a `[Conditional('DEBUG')]` attribute, and when I removed the call to it, the time went down to 64 seconds, 63 of which was in a very simple function. A LINQ statement in there could be re-written to make it 120ms. I ended up contributing it to EF core, being acknowledged in their blog post, and we ended up using our own release build of EF libraries until the fix made it to the public release. Had they not open sourced EF, it could turn into an existential threat to the project.