There are scenarios in which NHibernate performance decrease 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 record ( 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 term of speed. Other cases happens 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 provider some IDbConnection extension methods, those methods works on an already opened connection, so we can use the connection sticked 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 don’t 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 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.

In this post Ayende talk about when we should use NHibernate and he point that in almost read only scenario other approach can be preferred. I think he forget to mention the fact that even in such a scenario we can leverage a very reliable multi DB abstraction offered by NH that can help us if we think to target different data platforms. In order to me we should say that the point of decision to choose fro NH to another approach is the ability to create an entity model, and an entity model helpful to our objectives. This can also depends on how much we are confortable with the technology. Another interesting extension of the argument is, if we should not  use NH what can we use instead ? Well not for sure EF, since the reason of renounce to NH in a project should be the same to avoid EF. The NOSql solutions works only if we can completely avoid a relational database, and the pure crude ADO.NET is just ugly. An option could be Dapper,  a lightweight OR/M ( not exactly an OR/M, but almost ) that remove all the ugliness of ADO.NET and does not change the performance in comparison on using the manual data access approach. I did not tried it myself, but one of its users is stackoverlow, so this should be by itself a guarantee.