Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Yes.

> This is mostly false. ORMs are far more efficient than most programmers believe. However, ORMs encourage poor practices because of how easy it is to rely on host language logic (i.e., JavaScript or Ruby) to combine data.

The ORM encourages this, unfortunately.

> Now don’t get me wrong, ORMs are not as efficient as raw SQL queries. They are often a bit more inefficient, and in some choice cases, very inefficient.

Maybe a bit pedantic, but this and what's above contradict each other.

The problem is essentially this: you shouldn't use the abstraction until you understand what you're abstracting. But that's not how we write software typically.



It's more that ORMs are often perceived to be far slower on average, but in reality, they are not that much slower most of the time, and only far slower in choice scenarios.

But yes, agreed on your comment on general abstraction.


If the performance hit is seen as the overhead of the actual object oriented pattern (assigning fields to objects, caching, etc), then yeah, not that much slower, after all, the allocations would have to happen at some point. Patterns like DataMapper pattern present an alternate path that gives ergonomic advantages while not hiding the hard parts of dealing with state AND being incredibly performant.

But the real performance cost of ORMs has always been what typically gets left on the table: well written queries and schema. Poorly written schemas inspire poorly written queries which in turn completes the ouroboros by inspiring poorly written indexes. And ORM's like ActiveRecord encourage this. One easy example of this is the Paranoia gem as an addon to ActiveRecord, which encourages the misguided pattern of keeping around old data in your RDBMS.. There are many more examples.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: