4 ms·

>Entity framework is one of the best ORMs Yes, I think it is the best ORM in terms of productivity, but it is very, very slow. This is usually not a concern fo

>Entity framework is one of the best ORMs Yes, I think it is the best ORM in terms of productivity, but it is very, very slow. This is usually not a concern for internal enterprise applications that only have a few people using them at a time though. I guess the other issue is just an issue with ORMs in general - you lose a lot of the in-built features of your sql database, which as projects progress, can ultimately result in you writing the same amount of code as if you didn't use the ORM. You also can't switch programming languages without rewriting the entire database section. Personally, I stopped using ORMs altogether because I find that they make easy things a little easier, and hard things harder, which isn't a very good value proposition overall. They don't really save me time anymore.

orthoxerox 5y ago
EF Core is not slow at all, especially if you disable change tracking, which you don't want in many cases anyway.
- pinetlk 5y ago
  No it is definitely very slow. Stackoverflow did a test once, and switched to their light-weight ORM. The thing is, you mention disabling change tracking, and then there are things like having to make sure you aren't accessing a field that is outside of the included fields to prevent multiple queries, etc, etc. When I write SQL, I just write it once, and then it lives forever going very fast. When I look back on the projects written in EF/Linq, they are still going year after year, still using up lots of resources. I could have just written them in SQL. Maybe it would have taken an hour more over the entire project (internal enterprise thing), but it would still be running to this day, quickly and efficiently.
  - mb_72 5y ago
    With ORMs I tend to write things with their native syntax, and then if necessary go back and speed up critical sections with SQL; it's not an either/or situation.
  - register 5y ago
    That was a long time ago. I believe it was based on EF and not on EF core. Is there any up to date benchmark that you are aware of? BTW I used both Dapper and EF for consumer based web applications with a mild load. Dapper is a nightmare to use compared to EF. Dapper was chosen by the customer architect as mandatory because probably of the same benchmark that you are referring to. The result has been that we had to write tons and tons of code to cover things that come out of the box in EF such as 1 to many relationships. Also every change in the schema forced us to review the full persistence layer to evaluate the impacts. I would reccomend Dapper only for websites dominated by SELECT queries on databases with simple DB schemas and only when some millisecond more make a difference. This wasn't absolutely the case for our application ( complicated DB schema and 5 ms vs 30ms spent in the ORM doesn't make any difference at all) while probably IT IS StackOverflow case. There is no such a thing as something slow or fast in absolute terms: it all depends on the context and as software engineers and even more architects we are called to judge with our brains everything in context rather than rely on a blog post written by somebody else.
  - DeathArrow 5y ago
    >Stackoverflow did a test once That was long time ago and EF improved a lot since then. But it can be slow if used improperly. But hand written SQL can be slow too if not carefully crafted.
    - sharken 5y ago
      Any SQL query can be slow, especially if you have a large database and/or use a lot of Foreign Keys within your database. Sometimes small changes in fragmentation, statistics or data composition will trigger a different queryplan which will affect your query immensely. Good monitoring and a DBA nearby would be your best bets to overcome this. The point is that using a relational database is not a trivial thing once the database becomes large. Until then its relatively simple.
4rt 5y ago
I don't think its a common opinion that its very slow. It builds queries and executes them very quickly compared to most. It does have a built in footgun where for some structures it defaults to invisibly lazy loading sub-collections, you can (almost certainly should) disable that and specifically tell it to populate that data in the first query using Include() or any of the other projection mechanisms. Is it possible you had that?
- Merad 5y ago
  Lazy loading has been disabled by default since EF Core came out.
CharlieDigital 5y ago
The most comprehensive benchmarks to track are the TechEmpower benchmarks as they are open source so you can see what each framework is doing: https://github.com/TechEmpower/FrameworkBenchmarks/tree/master/frameworks https://github.com/TechEmpower/FrameworkBenchmarks/tree/mast... The benchmarks model simple, but real world scenarios. It has breakdowns by EF, Dapper (the StackOverflow "micro-ORM"), MySQL, PG, and raw ADO.NET. It should be noted that EF and EF Core are not the same thing; EF Core is more or less a full rewrite: https://docs.microsoft.com/en-us/ef/efcore-and-ef6/ https://docs.microsoft.com/en-us/ef/efcore-and-ef6/ Recent benchmarks have EF Core catching up to Dapper. You can read more about Microsoft's focus on performance for EF Core here: https://devblogs.microsoft.com/dotnet/announcing-entity-framework-core-6-0-preview-4-performance-edition/ https://devblogs.microsoft.com/dotnet/announcing-entity-fram...
hackerfromthefu 5y ago
As others have noted, that's very outdated information. The other thing is that for all ORMS, for the small amount of queries where it really matters, you should drop down to hand-written SQL anyway if the juice is worth the squeeeeze!

orthoxerox 5y ago

EF Core is not slow at all, especially if you disable change tracking, which you don't want in many cases anyway.

pinetlk 5y ago
No it is definitely very slow. Stackoverflow did a test once, and switched to their light-weight ORM. The thing is, you mention disabling change tracking, and then there are things like having to make sure you aren't accessing a field that is outside of the included fields to prevent multiple queries, etc, etc. When I write SQL, I just write it once, and then it lives forever going very fast. When I look back on the projects written in EF/Linq, they are still going year after year, still using up lots of resources. I could have just written them in SQL. Maybe it would have taken an hour more over the entire project (internal enterprise thing), but it would still be running to this day, quickly and efficiently.
- mb_72 5y ago
  With ORMs I tend to write things with their native syntax, and then if necessary go back and speed up critical sections with SQL; it's not an either/or situation.
- register 5y ago
  That was a long time ago. I believe it was based on EF and not on EF core. Is there any up to date benchmark that you are aware of? BTW I used both Dapper and EF for consumer based web applications with a mild load. Dapper is a nightmare to use compared to EF. Dapper was chosen by the customer architect as mandatory because probably of the same benchmark that you are referring to. The result has been that we had to write tons and tons of code to cover things that come out of the box in EF such as 1 to many relationships. Also every change in the schema forced us to review the full persistence layer to evaluate the impacts. I would reccomend Dapper only for websites dominated by SELECT queries on databases with simple DB schemas and only when some millisecond more make a difference. This wasn't absolutely the case for our application ( complicated DB schema and 5 ms vs 30ms spent in the ORM doesn't make any difference at all) while probably IT IS StackOverflow case. There is no such a thing as something slow or fast in absolute terms: it all depends on the context and as software engineers and even more architects we are called to judge with our brains everything in context rather than rely on a blog post written by somebody else.
- DeathArrow 5y ago
  >Stackoverflow did a test once That was long time ago and EF improved a lot since then. But it can be slow if used improperly. But hand written SQL can be slow too if not carefully crafted.
  - sharken 5y ago
    Any SQL query can be slow, especially if you have a large database and/or use a lot of Foreign Keys within your database. Sometimes small changes in fragmentation, statistics or data composition will trigger a different queryplan which will affect your query immensely. Good monitoring and a DBA nearby would be your best bets to overcome this. The point is that using a relational database is not a trivial thing once the database becomes large. Until then its relatively simple.

4rt 5y ago

I don't think its a common opinion that its very slow. It builds queries and executes them very quickly compared to most. It does have a built in footgun where for some structures it defaults to invisibly lazy loading sub-collections, you can (almost certainly should) disable that and specifically tell it to populate that data in the first query using Include() or any of the other projection mechanisms. Is it possible you had that?

Merad 5y ago
Lazy loading has been disabled by default since EF Core came out.

CharlieDigital 5y ago

The most comprehensive benchmarks to track are the TechEmpower benchmarks as they are open source so you can see what each framework is doing: https://github.com/TechEmpower/FrameworkBenchmarks/tree/master/frameworks https://github.com/TechEmpower/FrameworkBenchmarks/tree/mast... The benchmarks model simple, but real world scenarios. It has breakdowns by EF, Dapper (the StackOverflow "micro-ORM"), MySQL, PG, and raw ADO.NET. It should be noted that EF and EF Core are not the same thing; EF Core is more or less a full rewrite: https://docs.microsoft.com/en-us/ef/efcore-and-ef6/ https://docs.microsoft.com/en-us/ef/efcore-and-ef6/ Recent benchmarks have EF Core catching up to Dapper. You can read more about Microsoft's focus on performance for EF Core here: https://devblogs.microsoft.com/dotnet/announcing-entity-framework-core-6-0-preview-4-performance-edition/ https://devblogs.microsoft.com/dotnet/announcing-entity-fram...

hackerfromthefu 5y ago

As others have noted, that's very outdated information. The other thing is that for all ORMS, for the small amount of queries where it really matters, you should drop down to hand-written SQL anyway if the juice is worth the squeeeeze!