Comments on: Of Course NHibernate Is Slow When You Use It Incorrectly

By: Larry Liston

Larry Liston — Mon, 12 Apr 2010 17:07:18 +0000

I would have to agree withe Bart regarding the “unit of work” statement. The application should determine this based on requirements and environment. It would seem that if performance was the #1 concern, an ORM (and it associated overhead) might not be advisable anyway. Regardless, loading a collection, dirtying them up, and shoving them back in the database is a real world scenario and a useful metric as long as the playing field is level.

By: Tuna toksoz

Tuna toksoz — Fri, 21 Aug 2009 07:49:29 +0000

Bart, I have enabled batching in NH too, and ensured the ID gen is not one of the bad ones. NH performed better. I am interested in your code.

By: Bart Czernicki

Bart Czernicki — Fri, 21 Aug 2009 03:02:05 +0000

@Davy,

Not sure you can speak in absolutes that a “unit of work” should be small. For example, in a Silverlight RIA application when there is a series of changes done to the objects on the client the changes are “committed” in large transaction batch involving many entities. I found that ADO.NET Data Services with EF performs better in these scenarios than nHibernate.

Depending on your application this could easily involve a ton of entities that require multiple changes. With EF even hundreds of changes batched performs really fast. If you think about hundreds of changed entities is not hard to achieve (15-20 related tables with 5 new “somethings” fully created).

By: NHibernate Talk 8/20/09 - Travis.Net.Blog

NHibernate Talk 8/20/09 - Travis.Net.Blog — Thu, 20 Aug 2009 22:48:54 +0000

[...] custom data layer to Nhibernate, choices that have to be made when choosing NH for your data layer.NHibernate Slow? Of course when used wrong. Published Thursday, August 20, 2009 4:30 PM by mxmissile Filed under: [...]

By: Tuna toksoz

Tuna toksoz — Thu, 20 Aug 2009 21:41:15 +0000

@Davy
I chatted with Gergely and fixed the issue (other than not being a real world case).
We changed FlushMode to FlushMode.Never and removed a bunch of .Flush() in record data test and enabled batching. .SaveChanges() is doing batching, so should NHibernate.

Results? Nh wins

By: Davy Brion

Davy Brion — Thu, 20 Aug 2009 20:13:47 +0000

@Gergely

as i mentioned in the post, the whole problem with benchmarks like yours (and the ones we’ve seen lately) is that they only test performance in non-realistic usage scenarios, it doesn’t really matter if it is fair to all of the compared ORM’s… if it’s not tested in typical ORM usage, then it simply isn’t relevant. Performance of ORM’s can only be measured in a meaningful way when they are compared in real-world situations. Performance differences in other scenarios are just not trustworthy.

And just for the record, if NHibernate would’ve beaten Entity Framework in most or all of the tests, i would still feel the same way about the results. They simply aren’t valid.

By: Arjan’s World » LINKBLOG for August 20, 2009

Arjan’s World » LINKBLOG for August 20, 2009 — Thu, 20 Aug 2009 15:58:03 +0000

[...] Of Course NHibernate Is Slow When You Use It Incorrectly – Davy Brion [...]

By: Gergely Orosz

Gergely Orosz — Thu, 20 Aug 2009 14:55:31 +0000

I would disagree with two things in this post:
1. NHibernate did not lose in the comparison. I’ve found that it’s far slower when it comes to storage than Entity Framework however is much faster when deleting objects. In the other cases the speed of the two were somewhat similar. And in the conclusion I’ve said that I wouldn’t choose between these tools based on their performance as there was no clear ranking.

2. The test was not a typical real world usage indeed, it pushed the limits of the tools and tried to do this in a fair way, the source is available for you to see. Session cache is probably not used in this test at all however this was meant to be a performance comparison test, not a load test.

By: Alberto

Alberto — Thu, 20 Aug 2009 14:47:13 +0000

Ok, I guess I’ll have to leave NHibernate for internal tools then

By: Davy Brion

Davy Brion — Thu, 20 Aug 2009 13:45:10 +0000

no, because it doesn’t really make sense to do so

By: Alberto

Alberto — Thu, 20 Aug 2009 13:44:24 +0000

Thanks, it’s just I’m trying to come up with reasons to use NHibernate at work, but it seems to be hard to convince some people to move on to an ORM and forget about complex stored procedures. Have you ever used an ORM for a back office system in a bank?

By: Davy Brion

Davy Brion — Thu, 20 Aug 2009 13:39:14 +0000

It’s certainly not ideal for that kind of work. If you use a stateless session instead of a regular session the performance will be acceptable, but you could always do better.

By: Alberto

Alberto — Thu, 20 Aug 2009 13:31:49 +0000

Hi Davy,

I’m new to NHibernate, have just played a little bit at home with it.
From what you’re saying I deduce NHibernate is not to be used on a back office system, where most of the work we do consists of reading files up, transform some data and store every line in the DB.

Am I right?

Thanks.
Alberto.

By: Davy Brion

Davy Brion — Thu, 20 Aug 2009 09:15:44 +0000

if there is still a performance difference between NHibernate and Entity Framework once Entity Framework has all of the same features in their Unit Of Work implementation, then i would agree

By: Ricardo Peres

Ricardo Peres — Thu, 20 Aug 2009 09:14:20 +0000

Davy,

I totally agree with you; also, I followed the (large) discussion between Oren and one of the authors of ORMBattle.NET, and I also tend to agree with him. However, I believe that is not the point on this case: both EF and NH implement the Unit of Work pattern, so the comparison between the two is valid, since they have the same purpose.

Don’t you agree?