4 ms·

EF is another overly architected + bloated fx from Microsoft. It's over 12x slower than other Micro ORMs like Dapper + OrmLite - Benchmarks at: http://www.servi

by mythz 14y ago

EF is another overly architected + bloated fx from Microsoft. It's over 12x slower than other Micro ORMs like Dapper + OrmLite - Benchmarks at: http://www.servicestack.net/benchmarks/#dapper http://www.servicestack.net/benchmarks/#dapper The benefit of Micro ORMs is that they bind to clean re-usable POCO's (which by nature can be re-used as DTO's, ViewModels, etc). Most of them also add features as DRY extension methods over the underlying ADO.NET System.Data.* interfaces, so there's no magic behaviour or heavy abstractions happening underneath, letting you add new features orthogonally (by adding your own DRY Extension methods in your own project), and you always have direct access to ADO.NET IDbConnection so you're never restricted when you need it.

Smudge 14y ago
Not sure which version of EF those benchmarks are using, or how representative it is. For what it's worth, the EF team has been focusing on performance for EF5 and is making some promising improvements: http://blogs.msdn.com/b/adonet/archive/2012/02/14/sneak-preview-entity-framework-5-0-performance-improvements.aspx http://blogs.msdn.com/b/adonet/archive/2012/02/14/sneak-prev... (Disclosure: I work at Microsoft)
- mythz 14y ago
  The benchmarks are from StackOverflow's Open sourced Dapper ORM project - the source of which is contained in their repo: http://code.google.com/p/dapper-dot-net/ http://code.google.com/p/dapper-dot-net/
- mythz 14y ago
  If you guys are so "open" why aren't your performance advances compared in context against other ORMs? Benchmarks means a lot more in context and are more meaningful when they're compared to alt fx's on the same hardware specs / RDBMS / network configuration, etc. But I guess it doesn't matter when you're still be the most popular .NET package http://nuget.org/packages http://nuget.org/packages (580k) whilst remaining more than a factor of times slower than the competition - that's the .NET OSS ecosystem for you.
Retric 14y ago
Ok, let's check this benchmark out, wait 500 iterations for a total of 651ms = ~1ms per iteration and no version numbers ahh never mind.
- mythz 14y ago
  That's selecting a single db row, feel free to extrapolate that out for multiple rows containing complex queries performed concurrently by multiple users. But I guess performance doesn't matter in places where EF is used.
  - Retric 14y ago
    But that's just it, you don't extrapolate benchmarks outside the context of the benchmark. Without testing it you don't know if selecting 2 rows an extra 1ms, 200ms or 0.001ms. Many ORM have high overhead per query but are optimized to handle large result set's so depending on usage loading 1,000 rows might be faster than it's competitors. PS: A lot of frameworks are actually setup to handle the least important case first, handling large result sets are generally more important than the overhead for tiny query's. It's nice to be able to for things to work so a query that returns 1/2 million rows still returns in 1/100th a second and you can start paging through that result set even if the behavior adds overhead in the simple case. Chances are there is a shortcut if you only want 1 result just look for .first or a similar shortcut.
    - mythz 14y ago
      You realize the overhead is simply in row mapping right? Naturally this problem only exasperates with more rows. Like most heavy ORMs it's not obvious what SQL a complex LINQ statement emits where it's common to fall into "pits of failure" where it converts to multiple sub selects or the worst case N+1 queries. I'm personally not a fan of Heavy ORM's their an abstraction over a simple DSL and EF remains unnecessarily bloated and complex. BTW we do measure + profile, and EF is amongst the worst performing ORMs out there. Please provide benchmarks to the contrary?
      - 14y ago
whileonebegin 14y ago
Have you tried EF Code First? It lets you define classes, with no inherited base class, that can be used with the Entity Framework.
- mythz 14y ago
  Yes, I've given it up because of inefficient emitted sql, broken LINQ > SQL magic (leaky abstraction), poor support of alternative RDBMS's and didn't run on Mono. Have you tried a Micro ORM?
- josephcooney 14y ago
  No base class, but add half-a-dozen attributes to every single one of your properties...

by mythz 14y ago

Smudge 14y ago

Not sure which version of EF those benchmarks are using, or how representative it is. For what it's worth, the EF team has been focusing on performance for EF5 and is making some promising improvements: http://blogs.msdn.com/b/adonet/archive/2012/02/14/sneak-preview-entity-framework-5-0-performance-improvements.aspx http://blogs.msdn.com/b/adonet/archive/2012/02/14/sneak-prev... (Disclosure: I work at Microsoft)

mythz 14y ago
The benchmarks are from StackOverflow's Open sourced Dapper ORM project - the source of which is contained in their repo: http://code.google.com/p/dapper-dot-net/ http://code.google.com/p/dapper-dot-net/
mythz 14y ago
If you guys are so "open" why aren't your performance advances compared in context against other ORMs? Benchmarks means a lot more in context and are more meaningful when they're compared to alt fx's on the same hardware specs / RDBMS / network configuration, etc. But I guess it doesn't matter when you're still be the most popular .NET package http://nuget.org/packages http://nuget.org/packages (580k) whilst remaining more than a factor of times slower than the competition - that's the .NET OSS ecosystem for you.

Retric 14y ago

Ok, let's check this benchmark out, wait 500 iterations for a total of 651ms = ~1ms per iteration and no version numbers ahh never mind.

mythz 14y ago
That's selecting a single db row, feel free to extrapolate that out for multiple rows containing complex queries performed concurrently by multiple users. But I guess performance doesn't matter in places where EF is used.
- Retric 14y ago
  But that's just it, you don't extrapolate benchmarks outside the context of the benchmark. Without testing it you don't know if selecting 2 rows an extra 1ms, 200ms or 0.001ms. Many ORM have high overhead per query but are optimized to handle large result set's so depending on usage loading 1,000 rows might be faster than it's competitors. PS: A lot of frameworks are actually setup to handle the least important case first, handling large result sets are generally more important than the overhead for tiny query's. It's nice to be able to for things to work so a query that returns 1/2 million rows still returns in 1/100th a second and you can start paging through that result set even if the behavior adds overhead in the simple case. Chances are there is a shortcut if you only want 1 result just look for .first or a similar shortcut.
  - mythz 14y ago
    You realize the overhead is simply in row mapping right? Naturally this problem only exasperates with more rows. Like most heavy ORMs it's not obvious what SQL a complex LINQ statement emits where it's common to fall into "pits of failure" where it converts to multiple sub selects or the worst case N+1 queries. I'm personally not a fan of Heavy ORM's their an abstraction over a simple DSL and EF remains unnecessarily bloated and complex. BTW we do measure + profile, and EF is amongst the worst performing ORMs out there. Please provide benchmarks to the contrary?
    - 14y ago

whileonebegin 14y ago

Have you tried EF Code First? It lets you define classes, with no inherited base class, that can be used with the Entity Framework.

mythz 14y ago
Yes, I've given it up because of inefficient emitted sql, broken LINQ > SQL magic (leaky abstraction), poor support of alternative RDBMS's and didn't run on Mono. Have you tried a Micro ORM?
josephcooney 14y ago
No base class, but add half-a-dozen attributes to every single one of your properties...