hi, all.
Have you ever profiled nHiber with some load tests? I did it and found something interesting. Test is to load 200k objects from DB. Here are two moments:
1) Almost 10% of all the time was spent to do the following:

I've replaced this with following:


2) After that 38% (!!!) of all the time was spent to perform AbstractEntityPersister.SetIdentifier(...) because of using reflection to set simple int-typed identity field. It wasn't done with LCG.

I'm working on it now. Will you use consider my modifications? Shall I post it here?

This is interesting. Can you submit a JIRA issue with your proposed patch? Thanks.

nayato

I'm curious, how much overhead did NHibernate add compared to just using ado.net to do the load? Similarly if you did a select query in nhiberante to just retrieve the properties without objects, how different was that?

Neil

Well, SqlReader did work (read 200,000 rows five times and fill objects (direct instantiation)) by 3,2 seconds while nHiber did the same by 52 seconds.


Sergey, the root of the evil in my test was that ID was mapped with nosetter accessor (to prevent direct assignment) so nHiber was using FieldSetter.Set which assign private field by reflection. I solved this issue and did some tests.
Can I send it to you by e-mail? JIRA seems to be a little buggy for me (always says that page is not found)...

BTW, now nHiber do this work by 27 seconds ;) 48% faster...

I'll check if other routines can also be optimised.[/quote]

Ok, send it by e-mail. By the way, which profiler do you use?

I'm using VS2005 built-in profiler. It seems to be ok 'cause actual time-tests say the same after optimization :)