3 ms·

maybe is a stupid and generic question, but I will ask it :) using the current libraries, for searching way to improve rails performance, where to you think th

maybe is a stupid and generic question, but I will ask it :) using the current libraries, for searching way to improve rails performance, where to you think there are hot places where is easy to go and improve? second one. I know that there is plan for rack2, and some clean-up. Can we dream to a more faster rails5? last one. Not related with your performance improvements. I found most of the time that AR is quite slow, and I always tend to use ActiveRecord::Base.connection.execute("query here"). What is your opinion about http://sequel.jeremyevans.net/ http://sequel.jeremyevans.net/ ?

schneems 11y ago
> 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 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 https://bugs.ruby-lang.org/issues/11375 and https://github.com/rails/rails/pull/20946 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 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 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/8ce1add6c66b84ae8e56727a784cce6f1d8dcca5 https://github.com/mime-types/ruby-mime-types/commit/8ce1add... and is a great human.
- sanderjd 11y ago
  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/ http://rom-rb.org/
  - chanks 11y ago
    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.
    - sanderjd 11y ago

schneems 11y ago

> 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 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 https://bugs.ruby-lang.org/issues/11375 and https://github.com/rails/rails/pull/20946 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 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 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/8ce1add6c66b84ae8e56727a784cce6f1d8dcca5 https://github.com/mime-types/ruby-mime-types/commit/8ce1add... and is a great human.

sanderjd 11y ago
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/ http://rom-rb.org/
- chanks 11y ago
  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.
  - sanderjd 11y ago