Click here to Skip to main content
13,249,504 members (56,461 online)
Click here to Skip to main content
Add your own
alternative version

Tagged as

Stats

6.2K views
3 bookmarked
Posted 12 Apr 2012

NHibernate Performance Hacks

, 12 Apr 2012
Rate this:
Please Sign up or sign in to vote.
There are scenarios in which NHibernate performance decreases even if we do all the effort to correctly use it.

There are scenarios in which NHibernate performance decreases even if we do all the effort to correctly use it. This could happen if we need in some circumstances to load a lot of records (I explicitly use record instead of ‘Entity’) from some relational structures, and doing this the OR/M way means overload the session with a lot of entities, that is painful in terms of speed. Other cases happen when we need to write or update something that is not properly represented in the entity model we have, maybe because the model is more “read” oriented. Other cases? I’m not able to grasp all of course, but I’m sure that you face some if you use an OR/M (not necessarily NH) in your daily basis. Using NHibernate an alternative could be using FlushMode=Never in session, but you still have all the OR/M plumbing in the hydrating entity code that negatively impacts the performances. I obtained impressive results in solving such a situation, by using Dapper, a so called single file OR/M. It is a single file that provides some IDbConnection extension methods, those methods work on an already opened connection, so we can use the connection stuck to the NHibernate open session, as here below:

// don't get confused by LinqToNh Query<> this one is the Dapper query
// acting on the CONNECTION :)

session.Connection.Query<MyDto>("select Name=t.Name,Mail=t.Mail " + 
        "from mytable t where t.Valid=@Valid",new{Valid=true});

You obtain back a big recordset of MyDto instances in almost the same time if you wire by hand a DateReader vertical on the dto, with all the error checking.

So Why Not Use It Always?

Because despite the name, Dapper is not an OR/M, it does not keep track of modified entities, it does not help you in paginating results or lazy load the entity graph, neither helps in porting from one SQL dialect to another.

Is This Strategy Used Somewhere Else?

You probably find it interesting to read this post by Sam Saffron, this solution is used in Stackoverflow.com combined with the LinqToSql OR/M to help when the OR/M performance are not enough.

By my test, I experienced a performance increase of 10x in a very hacking situation, but I can’t show the case since it is not public code. Something more scientific about performance is here.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

No Biography provided

You may also be interested in...

Comments and Discussions

 
-- There are no messages in this forum --
Permalink | Advertise | Privacy | Terms of Use | Mobile
Web04 | 2.8.171114.1 | Last Updated 12 Apr 2012
Article Copyright 2012 by Felice Pollano
Everything else Copyright © CodeProject, 1999-2017
Layout: fixed | fluid