Is ORM slow? Does it matter?

Question

I really like ORM as compared to store procedure, but one thing that I afraid is that ORM could be slow, because of layers and layers of abstraction. Will using ORM slow down my application? Or does it matter?

Answer 1

Yes, it matters. It is using more CPU cycles and consequently slowing your application down. Hear me out though...

But, consider this: what is more expensive? Server hardware or another programmer? Server hardware, generally, is cheaper than hiring another team of programmers. So, while ORM may be costing you CPU cycles, you need one less programmer to manage your SQL queries, often resulting in a lower net cost.

To determine if it's worth it for you, calculate or determine how many hours you saved by using an ORM. Then, figure out how much money you spent on the server to support ORM. Multiply the hours you saved by your hourly rate and compare to the server cost.

Of course, whether an ORM actually saves you time is a whole another debate...

Answer 2

Well, ideally, it will significantly speed up your development - allowing you to iterate over features and experiment with different aspects of your application in a way which was impossible before. When you're sure you've built what you want to build, you're free to peer under the abstractions to make sure everything is being written/read properly on disk.

I don't think "abstraction" and "optimization" are mutually exclusive - yes, all abstractions let you think at a level which might hide suboptimal performance, but good abstractions let you peek underneath when necessary, and worry about optimizing the details when the right time comes.

SQL is most certainly an abstraction, too, and a really complicated one at that. Some of the smartest hackers I know trade SQL in for flat files precisely because they can't stand not knowing how exactly their data is represented on disk. And a lot of the time, flat files are a lot faster than SQL.

Answer 3

Obvious answer: It depends

ORM does a good job of insulating a programmer from SQL. This in effect substitutes mediocre, computer generated queries for the catastrophically bad queries a programmer might give.

Even in the best case, an ORM is going to do some extra work, loading fields it doesn't need to, explicitly checking constraints, and so forth.

When these become a bottle-neck, most ORM's let you side-step them and inject raw SQL.

If your application fits well with objects, but not quite so easily with relations, then this can still be a win. If instead your app fits nicely around a relational model, then the ORM represents a coding bottleneck on top of a possible performance bottleneck.

One thing I've found to be particularly offensive about most ORM's is their handling of primary keys. Most ORM's require pk's for everything they touch, even if there is no concievable use for them. Example: Authors should have pk's, Blog posts SHOULD have pk's, but the links (join table) between authors and posts not.

Answer 4

Is ORM slow?

Yes ( compared with stored procedures )

Does it matter?

No ( except your concern is speed )

I think the problem is many people think of ORM as a object "trick" to databases, to code less or simplify SQL usage, while in reality is .. well an Object - To Relational ( DB ) - Mapping.

ORM is used to persist your objects to a relational database manager system, and not ( just ) to substitute or make SQL easier ( although it make a good job at that too )

If you don't have a good object model, or you're using to make reports, or even if you're just trying to get some information, ORM is not worth it.

If in the other hand you have a complex system modeled through objects were each one have different rules and they interact dynamically and you your concern is persist that information into the database rather than substitute some existing SQL scripts then go for ORM.

Answer 5

Yes, ORM will slow down your application. By how much depends on how far the abstraction goes, how well your object model maps to the database, and other factors. The question should be, are you willing to spend more developer time and use straight data access or trade less dev time for slower runtime performance.

Overall, the good ORMs have little overhead and, by and large, are considered well worth the trade off.

Answer 6

I've always found it doesn't matter. You should use whatever will make you the most productive, responsive to changes, and whatever is easiest to debug and maintain.

Most applications never need enough load for the difference between ORM and SPs to noticeable. And there are optimizations to make ORM faster.

Finally, a well-written app will have its data access seperated from everything else so that in the future switching from ORM to whatever would be possible.

Answer 7

An ORM will always add some overhead because of the layers of abstraction but unless it is a poorly designed ORM that should be minimal. The time to actually query the database will be many times more than the additional overhead of the ORM infrastructure if you are doing it correctly, for example not loading the full object graph when not required. A good ORM (nHibernate) will also give you many options for the queries run against the database so you can optimise as required as well.

Answer 8

I never really understood why people think that this is slower or that is slower... get a real machine I say. I have had mixed results... I've seen where execution time for a stored procedure is much slower than ORM and vise versa.. But in both cases the performance was due to difference in hardware.

Answer 9

I have found that the difference between "too slow" and "not too much slower" depends on if you have your ORM's 2nd level (SessionFactory) cache enabled. With it off it handles fine under development load, but will crush your system under mild production load. After turning on the 2nd Level cache the server handled the expected load and scaled nicely.

Answer 10

Using an ORM is generally slower. But the boost in productivity you get will get your application up and running much faster. And the time you save can later be spent finding the portions of your application that are causing the biggest slow down - you can then spend time optimizing the areas where you get the best return on your development effort. Just because you've decided to use an ORM doesn't mean you can't use other techniques in the sections of code that can really benefit from it.

Answer 11

An ORM can be slower, but this is offset by their ability to cache data, therefore however fast the alternative, you can't get much faster than reading from memory.

Answer 12

In a Windows Mobile 5 project against using SqlCe, I went from using hand-coded objects to code generated (CodeSmith) objects using an ORM template. In the process all my data access used CSLA as a base layer.

The straight conversion improved my performance by 32% in local testing, almost all of it a result of better access methods.

After that change, we adjusted the templates (after seeing some SqlCe performance stuff at PDC by Steve Lasker) and in less then 20 minutes, our entire data layer was greatly improved, our average 'slow' calls went from 460ms to ~20ms. The cool part about the ORM stuff is that we only had to implement (and unit test) these changes once and all the data access code got changed. It was an amazing time saver, we maybe saved 40 hours or more.

The above being said, we did lose some time by taking out a bunch of 'waiting' and 'progress' dialogs that were no longer needed.

I have used a few of the ORM tools, and I can recommend two of them:

• .NET Tiers
• CSLA codegen templates

Both of them have performed quite nicely and any performance loss has not been noticeable.

Answer 13

Is ORM slow?

Not inherently. Some heavyweight ORMs can add a general drag to things but we're not talking orders of magnitude slowdown.

What does make ORM slow is naïve usage. If you're using an ORM because it looks easy and you don't know how the underlying relational data model works, you can easily write code that seems reasonable to an OO programmer, but will murder performance.

ORM is a handy tool, but you need the lower-level understanding (that usually comes from writing SQL queries) to go with it.

Does it matter?

If you end up performing a looped query for each of thousands of entities at once, instead of a single fast join, then certainly it can.

Answer 14

Yes, ORMs affect performance, whether that matters ultimately depends on the specifics of your project.

Programmers often love ORM because they like the nice front-end cding environments like Visual Studio and dislike coding raw SQL with no intellisense, etc.

ORMs have other limitations besides a performance hit--they also often do not do what you need 100% of the time, add the complexity of an additional abstraction layer that must be maintained and re-established every time chhnges are made, there are also caching issues to be dealt with.

Just a thought -- if the database vendors would make the SQL programming environment as nice as Visual Studio, and provide a more natural linkage between the db code and front-end code, we wouldn't need the ORMs...I guess things may go in that direction eventually.

Answer 15

ORM can get an order of magnitude slower, not just on the grount=s of wasting a lot of CPU cycles on it's own but also using much more memeory which then has to be GC-d.

Much worse that that however is that the is no standard for ORM (unlike SQL) and that my and large ORM-s use SQL vary inefficiently so at the end of the day you still have to dig into SQL to fix per issues and every time an ORM makes a mess and you have to debug it. Meaning that you haven't gained anything at all.

It's terribly immature technology for real production-level applications. Very problematic things are handling indexes, foreign keys, tweaking tables to fit object hierarchies and terribly long transactions, which means much more deadlocks and repeats - if an ORM knows hows to handle that at all.

It actually makes servers less scalable which multiplies costs but these costs don't get mentioned at the begining - a little inconvenient truth :-) When something uses transactions 10-100 times bigger than optimal it becomes impossible to scale SQL side at all. Talking about serious systems again not home/toy/academic stuff.

Answer 16

It doesn't. Good ORM with support total SQL features is circumflex. See more at github: http://github.com/inca