I am currently working on a project where I am going to replace the Data Access Layer from a custom ORM to Entity Framework.(The product is almost complete and mostly any changes that will follow after its completion would be change requests or bug fixes).

  • When comparing the two ORM's what performance metrics should I consider and why?

The absolute most important metric would be the number of database queries executed. If the ORM's translation of the logical code result in a different number of queries, this will have an effect that will dwarf any other difference. You should be especially on the lookout for "n+1"-pattern where the ORM will perform an individual query for each item in a collection when you traverse sub-objects. At least in EF you often have the choice between eager and lazy (n+1) loading of sub-objects, so be sure you know how to use the ORM optimally before dismissing one or the other.

Second, you should look at the amount of data returned from the database. There could be a difference if one ORM performs some filtering on the client side and another does in the sql. Some ORMS are smarter than others in how they translate filters to sql. Obviously it is preferable to filter as much as possible on the database side.

If the ORM's on the other hand generates equivalent sql (which is not unlikely), the performance difference will likely be small, maybe even negligible, and you should base your choice on other factors like maintainability and developer familiarity.

| improve this answer | |
  • 2
    You might want to consider "developer performance" - ease of maintenance - as well. That could easily outweigh any other gains. – Dan Pichelman Mar 30 '15 at 18:37
  • @DanPichelman not as far as the users are concerned. Dev productivity is a one-off cost, user productivity is a cost that keeps on being invoiced. Are you writing a product for the devs benefit, or for the users? – gbjbaanb Mar 31 '15 at 7:48
  • 1
    Dev productivity is definitely not an one-off cost! How maintainable a system is directly translates to ongoing expenses to implement change requests and bug fixes. – JacquesB Mar 31 '15 at 8:44
  • @gbjbaanb A lot depends on how many users are involved. If the "higher performance solution" requires an additional couple of months of development & debug time, then it's unlikely that you'll make up for time lost over the life of the product by saving a few milliseconds per click (unless you're Facebook). – Dan Pichelman Mar 31 '15 at 13:27
  • I'm sure Apple focussed entirely on developer productivity to make the iPhone ... unless it spent extra time making sure it was right before shipping it, and took over the world. How many software packages that get shipped with known bugs and missing features are as popular with users? Here, Dan is saying that a nice, easy to use ORM that has runtime performance problems is better than one that is fast but less easy on the devs. The runtime benefit is the primary decision in choosing which to use, not the benefit to the devs. – gbjbaanb Mar 31 '15 at 13:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.