I've been busy loadtesting nHibernate (using loadtesting tools in vs 2005 and unit tests).

The bottleneck for nhibernate is definitely the creation and filling of objects using reflection.

When I noticed in the load tests that the cpu maxes out very quickly, I was very happy to find the 1.01 feature of using code-dom for the property setting. In theory, this should give a huge increase in my tests, since I made sure that my DB was not the bottleneck (100% cache hits).
However, this does not seem to be the case.

Could the author or the nhibernate project member that implemented the feature give more information about their tests?? He claims increase of 40%.

My test configuration:
One session factory for the duration of the tests
No logging: no log4net and no 'show sql = true'.
Both tested with constant load and increasing load

My findings:
using the codedom, the avg testTime increases from 3 to 3.3 seconds and the tests/seconds then decrease accordingly.
Cpu usage does decline somewhat, from 96.9 to 93% on avg.

I'm quite puzzled by the findings, since I should have seen a huge increase in performance. :?:

Can you give more details about the operations you are executing?

You may also try the tests in the project NHibernate.Tests.Performance...

Check that you are not using custom property accessors in your mappings, reflection optimizer works only when all fields of an object are mapped using default access (access="property" or no access attribute and no default-access setting).

Now there's a useful nugget of knowledge! That should be on a "Tips and Tricks" page on the web site.

indeed, that's a terrific tip and a dreadful limitation that I will not be able to work around in each situation. Is this an architectural limitation?

kpixel: the tests in nhibernate.tests.performance are not really realistic to my situation.

The operation i'm executing is pure selects, no updates,inserts, deletes.
It's basically getting the services we provide a user. That class has a few relations that are also fetched.

I think it's about 25 entities in the one unit test consisting of 3 types, 2 of which do not have any access modifiers.

The selects that are created are fairly simple selects that execute fast.

Do you need more information? If needed I can post my mapping files.

My project leads are going to decide on using nHibernate using performance as one of the biggest issues, so I'm quite busy on having a good story for them.

How does using access=field.whatever-naming-strategy affect all this? So far, I've set up all my mapping to use field access rather than property access, assuming it will be faster. For collections, I need to use field access because the properties are strongly typed and NHibernate can't handle them.

What reflection optimizer does is compile a function that sets or gets property values directly, without reflection, through public properties. This cannot be done if you tell NHibernate you want to access the field directly,or if you use non-public properties, as it is then impossible to compile such a function. As always, optimization comes at a price...

but one field with a non-public access strategy shouldn't influence the rest of my properties, should it?

Currently, it will. It might of course be possible to create a better implementation.

ah, i'm also getting a few of these:
[3824] - Disabling reflection optimizer for class xxx
[3824] - CodeDOM compilation failed
System.InvalidOperationException: Referenced class xxx has base class or interface xxx defined in an assembly that is not referenced. You must add a reference to assembly yyy.


This is fixed by sergey here: http://jira.nhibernate.org/browse/NH-476

So, i am going to try to download a latest build, to see if I can get that to work. :wink:

Actually, I looked closer at the code, and it can handle the hybrid case, but the optimizer isn't used if the class contains a custom accessor. I'll change that.

Sergey, After recompiling nhibernate with a .cs file I got from cvs, the reflection optimizer is indeed working.
Great!!

I will rerun my performance tests and post here.

Sorry to have been so naive about it before.

Okay, the tests do show some increased performance. (About 10%)

Still, we've also loadtested a similar situation with datasets. Altough we're not expecting even a similar performance, we're seeing a factor of about 6. I don't know if that is comparable to findings of other users.