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?
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.
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?