So, I've been investigating WORM vs NHibernate and think either would work for us. I like (very much) the simplicity of WORM (and find the complexity of NHibernate to be somewhat daunting), but NHibernate has somethings out of the box that I would have to modify WORM for (e.g. access to the mapping metadata that goes with an object).

I have run into a *huge* performance difference that I cannot  readily account for, though. Retrieving a significant number of objects from a SQL Server database can be 20-30 times faster in NHibernate. I'm using the Welter templates with WORM, and GenWise objects with NHibernate. 

Accessing a modestly wide table (40+ columns), NHibernate can retrieve 7000-8000 objects/second from a separate test SQL Server machine, returning 40,000 objects in about 5 seconds. The WORM+Welter combination takes over 2 minutes to retrieve the same object set, barely 300 objects/second.  With an Oracle database, the difference is less, but NHibernate is still 3 or more times faster, 800 objects/second versus WORM still being around 300.

Of course, this isn't something you would generally actually have to do in production, but I was just trying to weigh whether the "bloat" of NHibernate was a performance detriment. Also, the performance of WORM improves dramatically if fewer objects are retrieved. Speeds of 1000-1500 objects/second are attainable when 5000 or fewer objects are retrieved.

Note that this is not the database. The query is finished, and I can see the client CPU go to 100% while the result set is actually being loaded into the objects with both mappers. I also repeat the test several times with the same query to be sure that caching issues don't muddy the waters.

Any thoughts? All I can come up with is that NHibernate generates lightweight property accessors while IObjectHelper (in the Welter templates) uses a big switch statement that string compares 1/2 the properties on average just to find a single property, property loading is O(n) in NHibernate versus O(n x m). Maybe I'll try a hash table instead just to see if this makes a different in my Welter object. I can also turn off the optimizer in NHibernate and see what difference that makes.  

I just tried turning off auto-tracking, and it didn't make much difference.

Performance goes down dramatically with result set size increase. I can retrieve almost 1500-1700 objects / second if I keep the result set size under 2000 objects, but it goes down steadily from there. 10,000 object can be retrieved in a little over 50 seconds (600/second), and down to 300/second for 40,000 rows.

I wonder if there is some sort of O(n) list access going on. I'll wade in a bit deeper.

Here's what I know:

1.  My ORMapper was definitely optimized for small to medium resultsets intentionally.  I'm a firm believer that you should use database paging and users should only see small sets.  The cases where you must have more are typically for reports, when DataSets make more sense and will outperform objects anyhow (even NHibernate I would bet from my own tests), or you should be doing the processing on the server if its not reporting.

2.  My ORMapper does not have any of the .NET v2.0 light-weight reflection stuff in it since I've kept the same codebase so far for v1.1 and v2.0, with the except of generics and nullables.  NHibernate probably has added that, which would make a difference, and I know that the results you're seeing were typical of all O/R Mappers in v1.1, including NHibernate, which was again part of my reasoning to optimize towards smaller sets.

Personally, I seldom even both with the IObjectHelper interface at all.  I added it since it makes performance tests better, but in the real world with smaller and more realistic sets of data it just doesn't impact performance the way it can in large theoretical tests -- and my mapper is all about what works best in those real world situations.

Thanks, Paul Wilson

OK, I found it. This really isn't a completely fair comparison after all, since ObjectSet has basically O(1) access by the key value and does does an expensive lookup to determine the index of the object at load time.

This line in ObjectSet_T.cs is the killer:

int index = this.Items.IndexOf(entityObject);

If I comment this line out, then I get object retrieval rates of 2000-2500/second, that don't decline with result set size. This is better.

I'll also try an ObjectReader.

Regarding the IObjectHelper stuff - if you look at the IL the compiler generates for the switch statement you'll see that the compiler emits code to load a static Dictionary<string, int> with the field names and a jump table index. When evaluating the switch arg, it looks up the string in the dictionary and jumps to the label indexed by the jump table index. So adding your own hashtable would simply replicate the code the compiler already generates for you.

I also found when profiling that when loading new rows from the database, the code calls DateTime.Now at least twice for each field in every row loaded. Since it was a non-trivial chunk of the time, I changed

return Instance.SetField(this.EntityObject, this.instance.Target, member, value, this.context.Provider);
to
return Instance.SetField(this.entity, this.instance.Target, member, value, this.context.Provider);

in this SetField overload:

private object SetField(EntityMap entityMap, string member, object value)

The other big hitter when running the profiler seemed to be QueryHelper.ChangeType. Since IObjectHelper necessarily has to coerce types anyway, it's superfluous if you have an IObjectHelper implementation. I didn't remove it, but the data suggested it would be the next thing to work on from a performance point of view.