Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 1 down vote favorite

This question is solely about using these technologies against stored procedures.

I've been doing quite a bit of reading on pitting these two against each other, and far more than anything I've been seeing them compared with CRUD operations and other more complex queries - very rarely for calling stored procedures.

I've read that it's hard to beat ADO.NET for performance when calling stored procedures. However, when calling them with Entity Framework 4.1, you get the benefits of entities (rather than just the data reader) which can be nicer to work with and pass around (imo).

I ran a few tests today (not sure of the accuracy of them) and they suggest that over 100 or 1000 iterations, calling the same procedure, that ADO.NET is something like 5 milliseconds, on average, faster per call. (I haven't been able to test how long it takes to convert from the standard data reader object to a similar kind of entity, but I doubt it makes up for the 5 milliseconds)

Is it worth the trade off in performance for the benefits in design and writing? Or are those 5ms per query just too much? Does the answer change between small projects, and environments like e-commerce?

share|improve this question

2 Answers

up vote 6 down vote accepted

The whole point of using ORMs is to make your life easier. There's always a trade-off between speed and convenience. Personally, I'd take a 5ms/call hit over having to deal with ADO.NET directly any day. As Juval Lowy is famous for saying, if you were really concerned with performance to start with, you wouldn't be using .Net.

share|improve this answer
Would your story change based on the environment you were in? – AndyBursh Aug 17 '11 at 18:09
@AndyBursh - I do not understand your comment. If the environment was not .Net4, I'd have to change because I couldn't use EF4. – John Kraft Aug 17 '11 at 19:17
I mean in the sense of the project. You might choose EF over something else in a small project, but what about on a larger one? – AndyBursh Aug 17 '11 at 19:49
I don't really think the size of the project has that much effect on my decision. However, I'm probably more likely to use an ORM on a large project than a small one. If you are asking about specific ORMs, there's a ton of them out there. They all have their positives and negatives; it's a matter of personal choice. I would probably still choose EF simply because it's included out-of-the-box with .Net4. – John Kraft Aug 17 '11 at 20:55
up vote 1 down vote

This "if you were really concerned with performance to start with, you wouldn't be using .Net" view is short sighted on what really causes performance bottlenecks in any serious internet application.

It's not your web application that's going to be the bottleneck, it's the database. You can scale out your web app easily, but you'll have to make a long list of considerations if you plan on taking the shortest step to scale your MSSQL Server.

So this millisecond delay is really insignificant, taking that if it ever becomes a problem you can just throw another web server in.

That said, using EF with stored procedures for all operations is fair game for any SQL application. You can pinpoint any Database performance and locking problems you might have to specific stored procedures and work on optimizing them, EF won't get in the way.

Generally ORMs are troublesome when you run into database performance problems and you have to start guessing where on earth were those locking queries generated.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.