3 ms·

If you're building a Rails app, just profile your queries (perhaps with New Relic) before pushing to production.

seliopou 15y ago
I don't think that NewRelic would help in this situation, as they only display SQL queries and the corresponding execution plan for slow queries in slow transactions. While this is certainly helpful, the blog post is pointing out the need for developers to know what their ORM is doing from the start, not just when a performance problem begins to manifest. Put another way, if you have good visibility into your system early on, and understand what's going on under the hood, you can avoid performance problems in the future.
- escoz 15y ago
  I agree with what you said about developers understanding what does on under the curtains, but regarding the NewRelic statement, I couldn't disagree more with this. Spending time early on in the project on things that don't matter and that don't really impact the system, like the example given in the post, is exactly the kind of thing that ends up creating projects that are expensive to maintain and just bad. Focusing on solving large performance bottlenecks, that can easily improve things 1000 times more than fixing that simple example is a much better use of your time, and is what newRelic shows you.
  - adelevie 15y ago
    This. At almost every level of web development, we're working with code that generates some other kind of code. Ruby -> C, Erb/Haml/whatever template => HTML, maybe Coffeescript -> JavaScript, and finally ActiveRecord/any ORM -> SQL strings. I write Ruby all the time, I don't know a lick of C. I've got a solid understanding of SQL and relational data modeling, but why should I check the generated SQL of _every_ single query? Furthermore, if you don't use an ORM, your model's methods will contain a lot of similar functionality. Hmm, maybe I should write a module or base class so I don't repeat myself. Eventually you will have written an ORM.

I don't think that NewRelic would help in this situation, as they only display SQL queries and the corresponding execution plan for slow queries in slow transactions. While this is certainly helpful, the blog post is pointing out the need for developers to know what their ORM is doing from the start, not just when a performance problem begins to manifest. Put another way, if you have good visibility into your system early on, and understand what's going on under the hood, you can avoid performance problems in the future.

escoz 15y ago
I agree with what you said about developers understanding what does on under the curtains, but regarding the NewRelic statement, I couldn't disagree more with this. Spending time early on in the project on things that don't matter and that don't really impact the system, like the example given in the post, is exactly the kind of thing that ends up creating projects that are expensive to maintain and just bad. Focusing on solving large performance bottlenecks, that can easily improve things 1000 times more than fixing that simple example is a much better use of your time, and is what newRelic shows you.
- adelevie 15y ago
  This. At almost every level of web development, we're working with code that generates some other kind of code. Ruby -> C, Erb/Haml/whatever template => HTML, maybe Coffeescript -> JavaScript, and finally ActiveRecord/any ORM -> SQL strings. I write Ruby all the time, I don't know a lick of C. I've got a solid understanding of SQL and relational data modeling, but why should I check the generated SQL of _every_ single query? Furthermore, if you don't use an ORM, your model's methods will contain a lot of similar functionality. Hmm, maybe I should write a module or base class so I don't repeat myself. Eventually you will have written an ORM.