Tony Davis

Simple-Talk Editor
News, views and good brews

The ORM Brouhaha

Published Thursday, September 03, 2009 2:21 PM

What is wrong with benchmarking software? Not much, you’d have thought. A while back, Laila Lotfi wrote an editorial on the need for a standard benchmark for Object-Relational mappers, such as Entity Framework and nHibernate. By how much do they really slow down database applications?

When the developers over at x-tensive.com, creators of the DataObjects.Net ORM tool, created a series of benchmarks much as Laila suggested, they published the results on the ORMbattle.NET website. Nobody could have imagined the resulting Brouhaha.

Derision has been heaped on the stated intent of the site, to provide an honest objective comparison of the performance of various different ORM tools for .NET. Instead, it has been portrayed as a "sleazy", "classless", underhand marketing trick using biased, inaccurate and unrealistic benchmark tests that were deliberately designed to show competing tools in the worst possible light.

There many complaints to the effect that the benchmark tests are useless, because the tool "should never be used in that way". If it can be, it almost certainly will be; and it is up to the tool creator to make sure that it stands up as well as its competitors. Although some interesting points emerged about the "bulk processing" nature of the benchmarks, and the manner in which transactions were used, any "knowledge shrapnel arising from the explosion of ORM minds" was largely drowned in a sea of acrimony, personal affront and mud-slinging. I imagine the sight of such a brawl sent a chill down the spine of managers who may have been planning to use ORM technology.

This comes at an unfortunate time. The IT industry is increasingly coming to suspect that the performance and scalability issues that come from use of ORMs outweigh the benefits of ease and the speed of development. DBAs will point unfailingly at the poorly optimised SQL that these ORM tools often produce. ORM supporters often accuse developers of not understanding of their tool and its features. If the latter is true, then such benchmarks are doubly important. It is not easy to produce realistic and fair benchmarks, especially for complex ORM tools, but if the community engages and perseveres, meaningful comparisons can be achieved, and one can learn a great deal from the process. We are crying out for objective benchmarks and if the ORM industry itself cannot hope to agree on how to do it, then perhaps benchmarks will have to be imposed on them.

As always, we'd love to hear what you think.

Cheers,

Tony.

Comments

 

Jason Haley said:

Interesting Finds: September 4, 2009
September 4, 2009 6:45 AM
 

Mark_C said:

Its also worth noting that due to protests from the NHibernate fraternity the tests were modified, they still showed poor results, so they continued to complain.

I can't possibly see how you can quantify the relative performance of anything without benchmarks, maybe thats the point - they don't want the performance of these frameworks to be analyzed and compared ?
September 4, 2009 7:52 AM
 

More ORM Ignorance | The Inquisitive Coder – Davy Brion’s Blog said:

September 4, 2009 8:42 AM
 

pho said:

I was an nhibernate non-believer at first, but never because I worried about performance, of all things.
There is no silver bullet, as developers will no doubt always find new ways to write ridiculous, bloated code.
I am aware that the following is an extreme comparison, but to illustrate the main point;
Would you write code in assembler instead of C# because it will be faster?
September 4, 2009 9:33 AM
 

Bill Barnacle said:

@pho
Yes I would, but then I am writing real time processing code. Nuts and bolts stuff, general programming then .Net languges are fine, and I actually prefer (here come the flames) C# to java.

But the point also applies to te use of ORM frameworks, the milliseconds add up when you are coding for production and large dataset processing. Thes tools are useful for anyone working with OOP code and databases, but be very aware of the limitations of ANY generalised code/database automation tool,
September 4, 2009 10:19 AM
 

BuggyFunBunny said:

I'll disclaim knowledge of the specific tool mentioned.  That won't stop me from ruminating.  I've been fed up with the very idea of ORM since they began to appear in the early days of java and thence .NET/C#.  The issue is the assertion of the existence of an "impedance mismatch".  I ran into Hibernate, and gagged.  Coders always try to twist data into some kind of convoluted file image.

The opposite approach can be seen in schema driven code generators.  Two I've looked at are Andromeda (which does maintain an off-line data dictionary) and sprox (which is python, but reads the schema directly).  In a time of SSD multi-processor/core machines, there is no reason not to build from BCNF data.  Views (may haps even the occasional Godzilla one) take care of the read side, and stored procedures take care of the write side.  The OO kiddies can have their bloated file images.  The other, oft ignored, benefit is the reduction or elimination of row re-writes, much beloved of those OO/ORM folks.  Send only the updated data, nothing more.

The real isn't the test harness.  It's ORM as concept that's in error.
September 4, 2009 6:13 PM
 

ovalsquare said:

What DBAs out there have had close experience with NHibernate? The whole DBA vs. ORM argument can sometime get tiresome if there's little crossover in the experience between the two parties.

This is where I first saw a problem with this post: 'because the tool "should never be used in that way". If it can be, it almost certainly will be; and it is up to the tool creator to make sure that it stands up as well as its competitors.' Anybody worth their salt as a developer must know what the benefits and limitations are to using a certain tool. You could take that statement and apply to virtually any other language/tool/etc. used by a developer. Using a screwdriver to drive in a nail doesn't mean the screwdriver is flawed - the user is. Or rather, at least the user's lack of knowledge. Hmmm...wait a minute, I just realised that Ayende (of NHibernate) used a similar, if not the same, analogy. In fact, there's nothing like a screwdriver when used to do what it's designed to do, but as I have a two year old boy, I can attest that a lot of damage can occur when using a screwdriver to do something it's not for.

I do not want a jack-of-all-trades when it comes to an ORM/data access. I want something that works and performs in the real world. And for me, NHibernate is currently phenomenal in what it does. But as with anything, including roll your own DAL, SPROCs, etc. make sure you benchmark it and aren't doing something stupid with it.

And yes, the post begins with "benchmarking is needed." Yes, it is. What I got sick of in the ORMBattle.NET aftermath was the far-from-humble, snide, and plain inaccurate responses from those involved with ORMBattle.NET. I should come up with some good examples, but I think I'll pass (perhaps immaturely) as I don't wish to give any more credence to those involved with ORMBattle.NET - they received much too much time on a soap box (and no, not because they provided benchmarks, but the method by which they did so, and attitudes they showed towards others in the .NET community in the aftermath).

I don't usually rant and I tend to be very positive. But I got tired of well respected and committed .NET community members being disrespected and accused of spreading FUD.

Past that, technically speaking, there's a much better argument in response than mine at
http://ayende.com/Blog/archive/2009/08/22/nhibernate-perf-tricks.aspx. Keep in mind when reading it that (in this case) Ayende Rahien's response is coming on the heels of a considerable number of patient (and I'm sure time consuming) previous responses.
September 7, 2009 11:20 PM
 

alexyakunin said:

Tony, thanks for the good post about us. I'm a long-term subscriber of Simple-Talk newsletter (although not via this account), so its today's content was a pleasant surprise for me :)

Kind regards,
Alex Yakunin
ORMBattle.NET fan #0, as well as CEO at X-tensive.com
September 7, 2009 11:59 PM
 

alexyakunin said:

@ overlsquare:

> What I got sick of in the ORMBattle.NET aftermath was the far-from-humble, snide, and plain inaccurate responses from those involved with ORMBattle.NET. I should come up with some good examples ...

Must I ask you to publish some quotations? I think you're exposing this here much worse than it really was.

Btw, I agree there were some ironical comments from my side. But the same is correct for the other side. Moreover, I think in such a case that's pretty normal: imagine what would you get after coming to e.g. Harley Davidson club and saying "your bike isn't fast at all because it is built in a wrong way". Constructive critics? I hardly believe so ;) The example is far from near, but it gives some imagination of what I got, and why sometimes I was answering ironically. It's hard to be cool when you hear no facts, but mainly FUD statements.

On the other hand, I'm almost 100% sure I answered on all the technical questions. And I'm still ready to answer them, especially if there is anything new. Although I don't promise to agree with you.

>  they received much too much time on a soap box (and no, not because they provided benchmarks, but the method by which they did so, and attitudes they showed towards others in the .NET community in the aftermath)

I think, on contrary, ORMBattle.NET is discussed so much _mainly_ because of results of our benchmark. There would be no any argues at all, if it would show #1 is NH, #2 is LLBLGen and so on. Moreover, I bet I'd got few positive posts from Oren Eini (Ayende @ Rahien) and Frans Bouma. But reality was different, as well as reaction of authors of these tools and its "extent" in their communities.

> Ayende Rahien's response is coming on the heels of a considerable number of patient (and I'm sure time consuming) previous responses

Oren actually wasn't patient at all. Check out his previous "How to lose respect..." post.

Moreover, I think he intentionally did 4 posts related to ORMBattle.NET. After all the tweaks we did NH was still showing itself as one of the worst players there. And in fact, there were just two exits from this situation:
- He could say "Ok, that's true... We'll think if it's necessary to work on NH performance".
- But he still continues to claim "Results are wrong because the whole benchmark is wrong".

Note that other players (e.g. Telerik) have credited it well (see its blog, f you're interested). And I expect this community will grow further.
September 8, 2009 12:34 AM
 

alexyakunin said:

P.S. Just re-read the post - I'm sorry for many mistakes ;) "did 4 posts" -> "made 4 posts" and so on...
September 8, 2009 12:36 AM
 

NullPointer said:

The only way this ORM war is going to stop is when everyone gets together and decides on a set of standards that allow someone to write a benchmark that everyone agrees on.  Then you'll finally have a yardstick to beat them all with ;)

I think the ORM developers are in many ways their own worst enemies though; they are constantly coming out to say "well, yes, our hammer is quite slow, use the screwdriver instead". Argh. Then throw away the hammer! Stop giving me hammers! Stop putting hammers at the top of the toolbox, and hiding the screwdriver way down at the bottom...

Personally when I started using NHibernate it was like a breath of fresh air. I thought, "this is it, I'll never again hand code a DAL". A few months later I vowed never to use it again. Not because it's a bad tool, but because I got tired of coming across the exceptions and the edge cases and the workarounds that ended up costing me more time than if I had just write the SQL myself. And I have experienced more or less the same issues one way or another with every ORM...but that's just the stuff I work on I guess, I'm not dissing ORMs in general.

Alex, I think maybe you need to give Oren a bit of a break. After all, you're trampling on his life's work here. Of course he's going to defend it; the fact that you have put so much effort into trying to hammer your opinion down his throat is not endearing you with the rest of the community.
I'd love to see how you treat your customers when you believe the issue is not your product but their use of it. Do you ring them back to argue with them as well?
September 8, 2009 3:44 AM
 

Ian Ringrose said:

I have worked on lots of different applications for different companies that don’t use ORM tools.  There has often (could say always) been problem with buggy and slow hand written SQL and Schema designs that led to unnecessary performance problems.  (A lot of this SQL is worse then what most ORM produces.)

Due to the account of hand written SQL (one project I worked on had over 1000 stored procs and over 300 database tables), it was close to impossible to sort out the Schema problems.

Most of the code in these many applications updated a “hand full” of rows while having to read lot of rows from the database to populate the UI and check if the edit is valid.  There never seems to be match code that does bulk updates.

So now I will get to the point….

Firstly I think we are hitting the problem that there are two groups of applications that use RDBMS.

Some applications have simple database scheams and undertake a simple well-defined function, but have to deal with a LOT of data and LOTS of users doing update at the same time.  These tend to be the domain of DBAs. (A high volume ecommerce website is a good example of this.)

Other applications have VERY complex data structures, are very configurable in how they behave, but don’t have many users updating the data at the same time.  These tend to be the domain of computer programmers.   (A CAD system or university time tablebeling system is a good example of this)

ORM are slower for simple bulk updates of many rows, however ORM can make the code a lot simpler and more maintainable in complex applications.   In the hands of an experience programmer that *understands* the SQL that the ORM produces, an ORM can perform very well.

But benchmarks tend to be simple, and if they are written by DBAs will have lots of bulk updates, as that is what DBAs do….

I think these days if your application has complex data structure you should use an ORM, but fall back to hand written SQL and Stored Procs for the few bulk updates you do need to do.  (If your schema is not standard, you should expect to have to customize how the ORM creates the SQL at some point, at least you only have to do this in one place rather then find all the badly written SQL)

Ian Ringrose
September 8, 2009 4:25 AM
 

Mark_C said:

Ian,

I think its the other way round, if you have a cmplex data structure you shouldn't use an ORM. If you have, say 12 tables in a small web app then use one.
Why ?
Through experience I've found if you have a complex schema with many relations the ORM I use (NH) starts pulling huge amounts of data that isn't needed, slowing performance down and increasing memory usage. Too long to explain here but when you see it pulling 20+ table joins when you only need data from say 3 or 4 tables you have to wonder.

I'll back up "NullPointer" on the issue of finding workarounds for things, it becomes far more costly.

The main defence for using a ORM appears to be "it avoids badly written data access layers".. well here's a thought.. don't write bad code!
I worked on a project that set down a base class for data access, instances of this were then code generated via an in house tool (that did alot else besides). the DAL was the only way to get at the database. We had no probems with it at all against a 500 table database. I can quite confidentally say if we'd of tried to use NH it would of failed. Sure there was time in writing the code gen tool, but it had paid for itself within months.
I don't think the fact it is possible to write bad code is justification for using any framework/tool/utility.
September 8, 2009 4:51 AM
 

datadump said:

The whole debate over the relative performance of the different ORM frameworks seems like two bald men arguing over a comb. We all know that in databases size matters. Once you start talking about terabytes, telling the difference between a query that returns a resultset in millisecs compared to one that will take 48+ hours requires a specific skill in RDBMS.

ORM is not a performance tool - it cannot automate or deskill the creation of the DAL. It's a RAD tool for those applications where the data volumes are not significant enough to require the input of a skilled DBA.
September 8, 2009 5:42 AM
 

alexyakunin said:

> I think its the other way round, if you have a cmplex data structure you shouldn't use an ORM. If you have, say 12 tables in a small web app then use one.

I disagree with this. The more complex structures are, the easier your life will be. Dealing with 1000K+ different classes is pretty normal case for such languages as C#, but dealing with 1000+ tables of completely different structure is really hell.

But it's true, it's better to avoid to complex LINQ queries in such cases. Try run nearly the same ones as you would consider acceptable for relatively simple cases.

E.g. if the model is complex, technically you can involve hundreds of relationships there. But this won't work. Likely, even on SQL. Just avoid this - that's it.

> Firstly I think we are hitting the problem that there are two groups of applications that use RDBMS.

I agree with this.

> But benchmarks tend to be simple, and if they are written by DBAs will have lots of bulk updates, as that is what DBAs do…

No, it is simple by different reason. See FAQ there.

> We all know that in databases size matters. Once you start talking about terabytes, telling the difference between a query that returns a resultset in millisecs compared to one that will take 48+ hours requires a specific skill in RDBMS.

I fully agree with this. Nothing will replace skills of tuning up the storage and writing better queries. But imagine if they are already ideal. Frequently this is exactly the case you have for terrabyte storages.

So see:
- http://ormbattle.net/index.php/faqs/85-what-results-of-your-benchmark-show.html
- http://ormbattle.net/index.php/faqs/84-when-results-of-these-benchmarks-are-applicable.html
- http://ormbattle.net/index.php/faqs/83-lets-imagine-one-tool-outperforms-another-one-by-100-but-database-operations-eat-90-of-time-so-total-difference-will-be-just-10-do-you-agree-with-this.html

Storage capacity isn't the only factor people take into account when they're talking about performance. Storage and application server load is frequently much more important one here.

If everything is implemented well, processing time must be approximately proportional to log(dataSize); but its dependency on load is worse: if you don't add processing units, it will be ~ O(concurrentRequestCount) or even worse.

So raw performance can be important even for tiny storages experiencing high load.  Even 10...100GB  storages are relatively rare, not saying about TB.

Note that frequently true performance killers (complex queries) are optimized so well there that there is simply nothing to go further.

P.S. Of course, it was a very rough estimation ;) I just wanted to illustrate my point of view by some numbers.
September 8, 2009 7:37 AM
 

Alex_Kuznetsov said:

Benchmarks and tests must be repeatable and simple. They don't have to be exactly realistic. Consider a car crash test. Can you imagine a car manufacturer going like this: "Our cars are not supposed to be used like this! RTFM! Users are supposed to use brakes and steering wheels to avoid collisions, not to drive head on into concrete walls! Such crash test are useless!" Of course, in real life almost all collisions are quite different from the ones in crash tests. More to the point, for every collision there usually are several close calls, so IMO the ability to avoid collisions is probably much more important that the ability to survive them. Yet crash tests are widely used...

Getting back to benchmarking ORM, the benchmarks do not have to look realistic either.
Suppose I am developing a system which needs to save individual facts into the database ASAP - it cannot afford to wait and accumulate a bunch of facts and save them all at once. Of course I will want to benchmark how fast it saves those individual facts. Of course my test will consist of some processing on the client, having the ORM to save something, and some processing on the server. To measure only how fast is saving with minimum noise, I will want to minimize both the processing on the client and the processing on the server. This is how I would come up with something very similar to the benchmark being criticized - a simple loop doing lots of calls to the middle tier and trivial changes on the database side.

I know about set based operations, and about bulk loading and such, but if I want to measure how fast is my middle tier at saving individual rows, I will measure what I want in the most efficient (for measurement) way. And don;'t tell me that I don't want to measure that - in many cases I definitely need to benchmark.
September 9, 2009 10:53 AM
 

NullPointer said:

@Alex_Kuznetsov:

I hear what you're saying about the crash testing but I'm not sure I fully agree, even though I agree with your post in general (!)

Crash testing _is_ realistic in the sense that world+dog knows that driving into a concrete wall is 100% of the time a bad idea; we go out of our way to avoid it but sometimes it happens (brakes fail, people do dumb things, etc). And the crash tests are to see what really happens in the worst case scenario where you have a crash, to try to minimize the damage.
I'm sure if you look very closely at for example BMW's safety guidelines there is something that mentions "do not drive this car into a wall"

And there's where my problem with ORMs in general comes in - there are so many ways to drive yourself head first into the wall *without even realising it*
NHibernate, for example - you see so many articles on performance tuning, where the author will say "well, ok, you want to do X. Now, you could do it using method A, or method B, but they're really slow, so use method C"...well the problem is, C is often unintuitive and buried at the bottom of the toolbox, whereas A and B are what you're "taught" to use.

Given that many other ORMs suffer from the same kind of problem, I just don't see how one can effectively write a benchmark that differentiates between them on anything except the most basic and trivial level.

Sure, you can show that Product X's setup and teardown for a given transaction running in a loop over a million iterations is 3 times faster than Product Y - then the guys who do X will say "ah yes but you shouldn't do that with X" and also "and by the way we're 5 times faster than Y for another type of operation"....you can't win.

That's why I originally said that until there is an independant body of some kind that is allowed to say what is and isn't an ORM, and what is and isn't the "right" way to perform a given operation, we will never have a true benchmarking system for ORMs. It will be like trying to compare cars and helicopters. They both perform a similar function (get from A to B) but any comparison between them is meaningless.
September 11, 2009 4:54 AM
 

Phil Factor said:

Cars are benchmarked the whole time. There are some absurd tests such as the MPG and 0-60 acceleration, but they have entered popular culture. Some people find them useful.
One car manufacturer found that the engine management strategy that the car required in order to pass the emissions test caused a considerable loss of power, and which affected both the MPG and acceleration figures. An engineer noticed that the government emissions testers always ran their tests with the car door open, on a special test harness. Brainwave. They connected the door sensor to the engine management system so that the lean-burn strategy switched in when the door was open, and the power strategy kicked in when the door was closed. Voila. The car performed well in all three benchmarks.
Benchmarks are, of course, abused. They can, be made to work, though.  
September 11, 2009 4:23 PM
 

meklembl said:

We continue to get personnel and sometimes bosses that want us to use tools to meet a need that it is not meant to meet.  Because it is handy I would sometimes use a screwdriver to pound in a ten penny nail.  Benchmarking is important to the DBA if the tests are repeatable over time.  I can not benchmark the same set of SQL across unmatched servers, but I can use the same set of SQL to set a benchmark on each server.  And as Mr. Phil Factor states, abuse of benchmarks does occur. Overall, I would definitely say they are important (christ this sounds like motherhood and apple pie), but you need to be consistent with what you are measuring and applying.
September 16, 2009 2:10 PM
You need to sign in to comment on this blog



















<September 2009>
SuMoTuWeThFrSa
303112345
6789101112
13141516171819
20212223242526
27282930123
45678910
Raw Materials: Command-Line Nostalgia
 Arthur finds philosophy deep in a dialog box. Read more...

Increasing Email Size Limits for your High Profile Users in Exchange 2010
 If you ever need to set up fine-grained rules to control the maximum size of messages a subset of your... Read more...

Product Review: Schema Compare for Oracle
 One of the more important tasks in the process of rolling out incremental developments to a... Read more...

Implementing the OUTPUT Clause in SQL Server 2008
 In retrospect, it was probably the inclusion of the OUTPUT clause in the MERGE statement that gave... Read more...

SQL Source Control: The Development Story
 Often, there is a huge difference between software being easy to use, and easy to develop. When your... Read more...