Hacker News Reader

Comment by yndoendo | Hacker News Reader

Last time I tried Entity Framework it was slow. Replaced it with Dapper and a simple custom migration system. This took database validation and seeding from 10 seconds to less than 2 seconds during startup on low powered hardware with SQLite. The queries created by Entity had pointless cascade of multiple join statements.

I have been reaching for GO with simple tooling and HTTP back end. .NET is useful for other solutions.

I have had too many issues with their frameworks, like WPF, needing to implement Win32 hacks. Example, .Net 9 was the first Windows version that properly returns all network interfaces. Older runtimes only expose Enabled NICs. I still have to maintain Windows 7 support for some solutions.

View on HN

I just went the other way and tore all my Dapper + SQL and repositories out of a big project and switched it all to EF Core 10. Not noticed any change in performance but dumped thousands of lines of unnecessary code. I like the tighter code, but you definitely do need to keep your eye on the "magic" of EF to avoid it doing anything goofy that isn't easily visible.

We use newer Entity Framework (Core) in a few large projects with zero issues. Even have Dapper and moving away from it as it brings nothing to the table but strings and bunch of SQL.

ef core is great for simple queries and modification of your data while using the changetracker. You can use AsNoTracking/Projection to perform similar like dapper for queries. When using command query seperation you can also use dapper for queries and ef core for commands.

We are also running into more and more performance issues with EF. There are ways to tune it but I am not sure if it’s worth learning this for EF or if it’s not better to just go for straight SQL. Seems MS has this tendency to create abstractions that then don’t work 100%. I see this with .NET too. Often you have to go down to Win32 for apps that are tightly coupled with Windows and hardware.

Is not that the core problem with ORMs. All of them. In the end you do straight SQL when it comes to Performance.

Are you talking about EF or EF Core? If the later, did you enable any or all of the magic like automatic property evaluation/eager fetching etc.?

EFCore by default is pretty performant - and pretty basic. You need to manually .Include() joins etc. which makes it pretty hard to become slow.

EF Core. It’s fine to some degree but larger queries with lots of joins can get very slow. Not all but just some of them.

The trick with EF Core is to let it do the simple stuff and if you need anything more complicated than .Include write the query yourself.

What version was it?

Reply on news.ycombinator.com