LINQ tests
We think it shows what kind of team is standing behind a particular ORM.
It's quite difficult to reach good result on LINQ tests, because LINQ implementation is hell. Even EF looses some points there - mainly because they don't support equality comparisons for references (fields of Entity type; or, better to say, comparisons of non-primitive types) and few other strange limitations like impossibility to use First/Single in subqueries.
Try to count how many full featured LINQ providers are there. Likely, less than your arm fingers. For the whole world. Now compare this to count of implementations of other query languages: hundreds or thousands. Why it's so complex? Because it's quite generic. It's easy to implement a particular case, or a set of them. But with LINQ, you must implement everything (or almost everything). Otherwise it simply won't work.
Performance tests
There are two equally interesting points:
- We think performance is always related to code perfection. You simply can't write high performance code without deep knowledge of .NET internals. But such knowledge normally imply much more, e.g. good coding standards and practices. Even chosen architecture significantly affects on test results: if you deal with "fat" entities, you have no chance to get high score in materialization test. Why you don't deal with slim ones? Likely, you don't know well how .NET performance is sensitive to memory consumption. Ok, certainly, there can be good reasons for this. I mentioned this mainly as an example.
- And obviously, our tests show maximal performance you may expect on this ORM in similar conditions. These numbers are very useful itself - if you know them, you won't think about the reason of slow materialization or CUD operation rate on a particular ORM. Compare the numbers, and you immediately know whom you must blame first: database, ORM tool, or your own application.
Kind regards,
Alex Yakunin
