Comment by schneems | Hacker News Reader

Comment by schneems | Hacker News Reader

Parent Full thread

> where to you think there are hot places where is easy to go and improve?

I tried to write some fancy libs to pull out easy optimizations https://github.com/schneems/let_it_go. It wasn't dramatic but it did find some things to optimize. This lead me to: https://bugs.ruby-lang.org/issues/11375 and https://github.com/rails/rails/pull/20946, though again neither is game changing. I really like this collection of micro optimizations: https://github.com/JuanitoFatas/fast-ruby. I would love to see a tool written that auto suggests code changes. I like http://github.com/schneems/derailed_benchmarks which is what i used for finding object hotspots in that PR. Ultimately I am counting on the VM to make my world easier and faster, as I mostly like writing ruby code, not mangled and optimized barely recognizable ruby code.

> Can we dream to a more faster rails5?

I think we're to the point where there's not many low hanging performance optimizations at the low level. Most apps that are really slow are slow because of their codebase and not Rails, that doesn't mean we shouldn't make Rails as fast as possible. Many of these optimizations I made here were found based on my apps use of the Rails api. I'm hoping others will benchmark their apps and look where we can save a few fractional milliseconds here and there. It's all the small speed-ups that make an overall faster product.

> I found most of the time that AR is quite slow

There are different APIs that are faster than others, i believe the `Model#find` where you pass in a primary key is pretty fast. I actually had a hard time finding any optimizable code in AR, MR. Patterson and Sean Griffin have done a great job of optimizing, though each codebase and use case is different. I've used sequel and really enjoy it. Jeremy writes some amazing code https://github.com/mime-types/ruby-mime-types/commit/8ce1add... and is a great human.

On the third point, my sense is that the part of AR that is often expensive is building full objects, when you often only need a few of their attributes. This is not such a big deal with a single (or a few) `find`s, but often is when you're grabbing lots of records, even when using `includes` properly. I find myself using `pluck` frequently when tracking down performance issues.

I often wish for a pared down database interaction API (I hesitate to call it an ORM) that just exposes raw data, and provides a convenient query interface (like AR does, but also like raw arel). Maybe this is what Sequel does, and I should be using that, I'm not sure. I was excited about datamapper2 and I've looked at ROM[0], but I'm not sure it's what I'm dreaming of. I could probably cobble it together by using existing database driver gems and arel directly. Unfortunately, as is usually the case when considering venturing off the beaten path of Rails, this sort of thing would give up a lot of the "conventions" advantages of Rails. AR pretty much is Rails.

[0]: http://rom-rb.org/

That is, indeed, what Sequel does. You can query the database object directly (for example, `DB[:posts].where{comments_count > 5}.exclude(poster_name: "Bob").order(:comments_count.desc).limit(10).all`) and get back an array of hashes.

Sequel's model layer is also faster than ActiveRecord's, because much of the additional functionality that ActiveRecord piles onto all records (dirty tracking, single table inheritance, etc.) are available in Sequel via a plugin system. You can enable the plugins you want to use and not pay the overhead of all the others. You can even enable specific plugins for only the models where you'll actually want to use them.

It also has a lot less magic (no association proxies, unless you enable the plugin for them :)), ridiculously customizable (many more options for associations, custom eager loading logic, and so on), and has an implementation of its Postgres adapter written in C for performance.

Highly, highly recommended.

Edit: Oh, and an issue tracker that is almost always at zero, with a very fast response time. As someone who has contributed a patch to ActiveRecord, I can't tell you how nice that is.

Yeah, that does sound like exactly what I want. Still has the "conventions" problem I mentioned, but maybe worth it, and common enough that it isn't that big a deal.

To your edit: Ha, I have a PR against arel that is similarly neglected[0]. Maybe an advantage of using a less popular library is that the maintainers aren't so overwhelmed that things get lost in the shuffle!

[0]: https://github.com/rails/arel/pull/320

   On the third point, my sense is that the part of AR 
   that is often expensive is building full objects, 
   when you often only need a few of their attributes.

This totally correct in my experience.

Reply on news.ycombinator.com