3 ms·

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

by 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?
  - Retric 14y ago
    As to personal benchmarks. The last set of tests I ran the direct ORM overhead consisted of between 0.2% and 2.3% of our page load times so we promptly focused on things that actually mattered (mostly JS). The ORM advantage is mostly in being able to get a demo to work quickly vs. spending less time optimizing complex queries, which means you only really spend time looking at the slowest stuff which can warp how you look at things. PS: If you have demo's that EF adds linear overhead feel free to show it but I have pulled 1,000 rows in under 1 second so I suspect your have messed up your setup somewhere.
    - mythz 14y ago
      Where are these benchmarks? Is this for a single call? How big are the rows? Have you compared it against anything else?

by mythz 14y ago

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?
- Retric 14y ago
  As to personal benchmarks. The last set of tests I ran the direct ORM overhead consisted of between 0.2% and 2.3% of our page load times so we promptly focused on things that actually mattered (mostly JS). The ORM advantage is mostly in being able to get a demo to work quickly vs. spending less time optimizing complex queries, which means you only really spend time looking at the slowest stuff which can warp how you look at things. PS: If you have demo's that EF adds linear overhead feel free to show it but I have pulled 1,000 rows in under 1 second so I suspect your have messed up your setup somewhere.
  - mythz 14y ago
    Where are these benchmarks? Is this for a single call? How big are the rows? Have you compared it against anything else?