3 ms·

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 t

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.

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.

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.