[ACCEPTED]-Is ORM slow? Does it matter?-orm

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

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

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

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

Is ORM slow?

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

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

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

Does it matter?

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

ORM's are slower and do add overhead to 20 applications (unless you specifically know 19 how to get around these problems, which 18 is not very common). The database is the 17 most critical element and Web applications 16 should be designed around it.

Many OOP 15 frameworks using Active Record or ORMs, developers 14 in general - treat the database as an unimportant 13 afterthought and tend to look at it as something 12 they don't really need to learn. But performance 11 and scalability usually suffer as the db 10 is heavily taxed!

Many large scale web apps 9 have fallen flat, wasting millions and months 8 to years of time because they didn't recognize 7 the importance of the database. Hundreds 6 of concurrent users and tables with millions 5 of records require database tuning and optimization. But 4 I believe the problem is noticeable with 3 a few users and less data.

Why are developers 2 so afraid to learn proper SQL and tuning 1 measures when it's the key to performance?

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

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

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

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

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

• .NET Tiers
• CSLA codegen templates

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

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

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

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

Is ORM slow?

Yes ( compared with stored procedures )

Does it matter?

No 19 ( except your concern is speed )

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

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

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

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

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

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

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

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

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

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

Obvious answer: It depends

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

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

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

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

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

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

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

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

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

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

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

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

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