4 ms·

I worry that this sort of article could be misinterpreted easily, even with the disclaimer. It's talking about optimizing something that takes less than 1% of

• mattetti 15y ago
  I hear you, but my point wasn't to show how to optimize AR but instead what's going on when you initialize a model. In other words it's more about software design and architecture decisions than performance.
  • scriby 15y ago
    "Performance cost of Ruby ORM model instantiation" may not have been the best title :)
    • mattetti 15y ago
      Agreed, the post title is actually "Quick dive into Ruby ORM object initialization".
• jamesbritt 15y ago
  My take-away was that it's a good example of how to think through software behavior and measure things. When and where the results might matter are a different issue.
• jeffdavis 15y ago
  "It's talking about optimizing something that takes less than 1% of the vast majority of an application's cycles." What takes the other 99%? Did you measure?
  • scriby 15y ago
    Yes. At least in my own apps. Model instantiation being a bottle neck practically implies that you generate models in a tight loop and do nothing else with them, such as persisting them.
    • bricestacey 15y ago
      But, people do precisely that. I was working with parsing log files and converting each row to a Mongoid object took forever. It was in a tight loop and did nothing but persist it. So, I had to drop into the Ruby Mongo driver, avoiding the ORM altogether.
    • jeffdavis 15y ago
      So, what took the other 99% if not model instantiation?
• ssmoot 15y ago
  Developers perhaps not as well informed could do themselves a real disservice by reading your comment to mean this stuff doesn't matter. I think we'd agree that yes, Model instantiation most likely doesn't matter. On the other hand, Model materializaion and query-interfaces most certainly DO. In fact, in your _average_ Ruby Web Application, there's a good chance that the O/RM and template rendering makes up the vast majority of your request time. Not database calls. Not controller logic. Only the Ruby side of O/RM interaction and rendering templates. It's impressive that 37Signals has gotten most requests to process in under 50ms for Basecamp Next. The truth though, that you frankly don't hear often enough, is that that's not exactly any great accomplishment for many languages/frameworks. I've worked on ASP3 and ASP.NET applications that had the same performance using hardware that was easily five times slower than anything you could buy today. The kicker is that that kind of performance came with entirely uncached pages delivering hundreds and oftentimes thousands of rows of financial reports. Back to basics, if you want it fast, it's a good bet that a simple DAL using Sequel Datasets is going to outperform just about anything else. Skip the models when all you're doing is dumping data for display. After that, see what you can do about limiting interpolation and String instantiation in your templates. That's where all your Template time is going. It's something you can build in a little bit at a time, and worrying about 5% here, and 20% there definitely will add up.