3 ms·
> The query translation and hydration overhead of transforming the data into objects even in a fast language are always going to be problems No they are not. H
by olavk 8y ago
> The query translation and hydration overhead of transforming the data into objects even in a fast language are always going to be problems
No they are not. Have you measured this in a real-world application? This overhead is negligible compared to the cost of the query itself. And without an ORM you still have to load the data into some kind of objects or data structures before you pass it to presentation, you will just have to write the code yourself.
But yeah, lazy loading in a loop will kill performance. So don't do that.
- NightlyDev 8y agoIt's definetly not always going to be a problem, but sometimes it does. ORM is always slower than writing custom code, but it might be more than fast enough.
- olavk 8y agoSurely it depends on the custom code in question if it is faster or slower than the similar ORM logic? You may be able to write faster code, but unless you are Donald Knuth, you can't guarantee that any custom code you write will always be faster than some library.