views:

516

answers:

2

I have search the internet high and low looking for any performance information for LLBLGen Pro. None found. Just wanted to know how does LLBLGen Pro perform compared the Nhibernate. Thanks

+4  A: 

Initially we tested LLBLGen @ ORMBattle.NET, it was ~ 2 times faster than NH on materialization; LINQ query compilation time was pretty good (~ 4000 queries/sec.), but CUD operations were noticeably slower than in NH (there is no CUD batching in LLBLGen).

Both frameworks must be relatively slow in case when you deal with large amount of objects in the same session:

  • NH is relatively slow because of its materialization pipeline. I'm not fully sure why, but e.g. to implement dirty checking, NH must store a clone of any materialized objects somewhere. At least two times more RAM ~= at least 2 times slower.
  • LLBLGen uses relatively "fat" entities - it seems they store fields in dictionaries. Obviously, this isn't good from the point of performance, since RAM consumption is one of essential factors affecting on it.

See this FAQ question and Test Suite Summary for a bit deeper explanation.

So in short, LLBLGen Pro must be faster than NH on reads, but slower on writes.

Alex Yakunin
ORMBattle.Net is a highly controversial website, created by the makers of an ORM tool that competes with both LLBLGen Pro and NHibernate. At MINIMUM, please consider the source before putting a lot of stock in this answer.The following is a blog post by one of the main contributors of NH, with a number of comments by Frans Bouma, the lead dev of LLBLGen:http://ayende.com/Blog/archive/2009/08/15/benchmarks-are-useless-yes-again.aspx
Phil Sandler
Performance tests are here: http://code.google.com/p/ormbattle/source/browse/#svn/trunk/Tests/Performance
Alex Yakunin
In response to "controversial website" (that's true - there were lots of argues around it), I'd also recommend to study the blog @ ORMBattle.NET to study the author's point of view.
Alex Yakunin
+4  A: 

Your question is essentially impossible to answer without context. The questions I would ask in response would start with:

  • What kind of application? Data-centric? Business logic-centric?
  • How much data are we talking about?
  • What kind of data operations are we talking about? Mostly reads? Mostly writes?

As a general matter, LLBLGen performs very well. We have used it on 10+ projects (including a few enterprise-scale projects) where I work, and the few issues we've seen with performance were always the result of misunderstand what the code was doing (there is a learning curve) or a poorly implemented physical model (e.g. missing indexes).

The two frameworks approach the problem of data access very differently. LLBLGen's operations generally translate into SQL that is fairly easy to understand if you have a strong data background. NHibernate uses sessions and cache to keep data in memory when possible to improve performance (disclaimer: I am not an NHibernate expert). LLBLGen does not support this sort of concept; instead it works in a disconnected state and stores change tracking information directly on its entity objects.

Bottom line, the approaches the frameworks take are very different, and it's hard to predict which will perform better without knowing more about what your system does. In the right hands, either framework can be used to design a system where data access performance is not a major performance bottleneck.

Phil Sandler
what do you think about the entity framework?
Luke101
Hmmmm..I have read the link in your message and must say Nhibernate has been really getting attacked. Do you know any good books on nhibernate using .NET?
Luke101
I don't know any good NHibernate books--I would wager that a good starting point would be the blog I linked in my other comment (not the specific post but the blog itself).I believe the entity framework is the future, assuming MS is committed to continuing development on it (which I think they are). However, I don't think it is nearly as robust as LLBLGen or NH in its current incarnation.
Phil Sandler
LLB supports in memory filtering, so it wouldn't be too terribly complicated to move all or even just heavily used portions of your data into an in-memory cache. Combined with the capabilities of its Dependency Injection framework to detect changes globally and you'd be well on your way.
tbone