Comment by bkeroack | Hacker News Reader

Comment by bkeroack | Hacker News Reader

Another problem with ORMs is that they make performance diagnostics much harder. DB-side, you might have a list of worst-performing queries and examining it reveals a huge, hundred-line monstrosity of a query. Because the queries are ORM-generated and are not usually very readable it isn't exactly clear which part of the application is generating it (or why). Even further, if your DBA says you could make the query more efficient by changing X and Y, it's not likely that you can take her advice since the query is programmatically generated! So you have the choice of abandoning the ORM in performance-sensitive paths and inserting raw SQL (making the code ugly) or living with poor performance.

I'm a fan of abstractions only when necessary. I want to have control over 100% of the code stack. When performance issues crop up (and they inevitably will), I don't want to just shrug and go "well, Hibernate must be doing something weird..."

This is simply not true, lots of tools are able to tell you exactly which line of code is responsible for which query.

Such as? Using ASP.NET and NHibernate, I've not seen any way to do this other than old fashioned log statements and guesswork.

http://www.hibernatingrhinos.com/products/nhprof

Worth every penny. You get full stack traces and line numbers automatically with each query.

Not sure about .net since I don't use it but for ruby there are a lot of monitoring services that do this (skylight.io, newrelic etc).

> So you have the choice of abandoning the ORM in performance-sensitive paths and inserting raw SQL (making the code ugly) or living with poor performance.

Most people ask themselves the same question and don't care much about performance. I'm glad you choose performance over code aesthetic. Code aesthetic should only come second to how the system performs. As for the ORM, it has it's downfalls. I've never heard of the N+1 query problem in the plain SQL world. It's a problem brought forth by ORM, because it's just stupid to even think about N+1 when you're trying to accomplish as much as you can in 1 query.

Django makes queries that are quite readable (and optimized! It makes good decisions to reduce the number of queries), and you can see exactly what SQL is run with the Django Debug Toolbar.

So "[ORMs] make performance diagnostics much harder" is just not true. "Some ORMs make performance diagnostics much harder" definitely is.

Reply on news.ycombinator.com