Is ORM slow? Does it matter? [closed]

Answer 1

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 2

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 3

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.