But the big surprise of the day was what happened with flushing from 2.0.1 to 2.1+. A basic flush on this process on 2.0.1 took .42 seconds, but on 2.1.1 it took .79 seconds. Really? What the hell happened in between those versions? Just to be sure I checked 2.1 and 2.0.1, both were the same. I wonder if abstracting dynamic proxying from NH had some unintended consequences.
Needless to say we are back on 2.0.1 for the time being. This process that was taking 1 min and 11 seconds now takes 47 seconds. Why? A couple of reasons: first the process calls embedded business logic many times that ends up doing "safety" flushing when it's a mostly readonly session. The next refactor is to fix that problem, but in all the flush increase difference accounted for 10 - 15 seconds. Second, was the proxies which accounted for the remainder of the difference. I didn't do anymore benchmarks on 2.0.1 vs Castle on 2.1.1, but I'm sure there are differences there from all the testing that was done. In either case there's not anything in 2.1+ that's worth these performance tradeoffs we experienced. NH.Linq seemed like it would have been a good move, but it's not yet ready for production use. So for now I'll take the perf benefits of 2.0.1 for the minor upgrades of 2.1+.
Nope, just Castle and LinFu. Haven't looked at the Spring stuff too much. Might be worth looking at sometime.
ReplyDeleteGet newer Castle Dynamic Proxy (v2.2) (you may want to download Castle ActiveRecord to obtain Castle.ByteCode, sinec NHibernate does not provide one).
ReplyDeleteNew version is faster when you generate many different proxy types (actual usage of proxies should have around the same performance).