4 ms·

But, if the code is being generated in that way, you're also doing a lot of identical string concatenation at runtime, when identical results with higher perfor

But, if the code is being generated in that way, you're also doing a lot of identical string concatenation at runtime, when identical results with higher performance can be achieved by doing it at an earlier point - compile, design, whatever. You're burning CPU cycles to avoid the existence of these objects and separetly make it harder to optimise your application later when you find you need it in places. Depending on your application architecture, you're also increasing the chances of your needing multiple round-trips to the database to query various bits of information for building your query, increasing the load on the DBMS (and possibly the network, depending on your architecture) and increasing the query latency. Properly auto-generated code should be the cleanest, best laid out, most consistent code you work on, quite possibly well commented as well. It's obviously not a panacaea that'll work for everything and I'm not saying ORM tools never have their benefits, but certainly I'm not convinced that third-party ORM tools are right for what I'm doing at present.

MartinCron 15y ago
Sure, ORM tools can be a tradeoff between what's fast at dev time and what's fast at runtime. What has been working for me is relying on the ORM and then hand-tuning the small subset of things that need to be hand-tuned. And, of course, I don't know anything about what you're doing at present, so I won't even try to speak to that. But I can't imagine a weaker argument against ORM than the first one you made, though. When you're doing data-intensive work, are you really worried about the CPU overhead of string concatenation on your application layer? :)
- eftpotrm 15y ago
  For a decent subset of the procedures I've worked on, yes, I am, from experience. I've had app performance killed by excessive string concatenation before, so my inclination to repeat identical jobs at runtime which I know from experience cause performance issues is limited. Precompile. I should stress in this though, I'm not a complete 'it must be a compiled sproc stored in the DBMS' guy; I have worked with systems before which effectively provided their own stored procedure implementation within the application source code because the underlying DMBS didn't support anything else; it's not ideal for a number of reasons but it does work, is an order of magnitude superior to ad-hoc SQL scattered throughout the app, still permits some of the benefits of genuine sprocs but also still provides the dev with proper control over what they're doing.

MartinCron 15y ago

Sure, ORM tools can be a tradeoff between what's fast at dev time and what's fast at runtime. What has been working for me is relying on the ORM and then hand-tuning the small subset of things that need to be hand-tuned. And, of course, I don't know anything about what you're doing at present, so I won't even try to speak to that. But I can't imagine a weaker argument against ORM than the first one you made, though. When you're doing data-intensive work, are you really worried about the CPU overhead of string concatenation on your application layer? :)

eftpotrm 15y ago
For a decent subset of the procedures I've worked on, yes, I am, from experience. I've had app performance killed by excessive string concatenation before, so my inclination to repeat identical jobs at runtime which I know from experience cause performance issues is limited. Precompile. I should stress in this though, I'm not a complete 'it must be a compiled sproc stored in the DBMS' guy; I have worked with systems before which effectively provided their own stored procedure implementation within the application source code because the underlying DMBS didn't support anything else; it's not ideal for a number of reasons but it does work, is an order of magnitude superior to ad-hoc SQL scattered throughout the app, still permits some of the benefits of genuine sprocs but also still provides the dev with proper control over what they're doing.