3 ms·

In my experience, most layers that make things easier generally suck under load. I would think it's especially true with something that adds a layer between yo

In my experience, most layers that make things easier generally suck under load. I would think it's especially true with something that adds a layer between you and the database. How is Active Record with regards to performance under load?

emmett 16y ago
ActiveRecord has great performance. Mostly because it's a really thin layer over database tables. The only additional overhead is instantiating one object per row returned.
prodigal_erik 16y ago
Much like other ORMs, ActiveRecord makes it almost effortless to accidentally do very stupid queries in bulk. For example (from http://guides.rubyonrails.org/active_record_querying.html http://guides.rubyonrails.org/active_record_querying.html) this code clients = Client.all(:limit => 10) clients.each do |client| puts client.address.postcode end looks harmless but requires eleven sequential round-trips to the database. This version clients = Client.includes(:address).limit(10) clients.each do |client| puts client.address.postcode end still requires two, and one of the queries gets bigger as the number of ids increases. You can get into find_by_sql, but at that point ActiveRecord isn't adding any value.
- rbranson 16y ago
  Sure, but how many times have you seen someone create something equal to that with SQL queries? Instead of using a join, they execute a SELECT against the database for every row they fetch. This is shockingly common in horribly written PHP code. In addition, ActiveRecord also supports joins instead of using includes. Includes is almost always fine, unless the initial result set is large (100+ rows).
  - chrisbolt 16y ago
    At least with SQL, it's obvious and not hidden by a layer of abstraction.
klochner 16y ago
You will definitely need to profile/optimize and hand code some queries. I ran into a bad one a while back (2.2.2): @foo = Foo.create @bars = Bar.find_all_by_some_attribute(:a) @foo.bars = @bars #--> slow! http://kevinlochner.com/rails-performance-inefficiencies http://kevinlochner.com/rails-performance-inefficiencies

emmett 16y ago

ActiveRecord has great performance. Mostly because it's a really thin layer over database tables. The only additional overhead is instantiating one object per row returned.

prodigal_erik 16y ago

Much like other ORMs, ActiveRecord makes it almost effortless to accidentally do very stupid queries in bulk. For example (from http://guides.rubyonrails.org/active_record_querying.html http://guides.rubyonrails.org/active_record_querying.html) this code clients = Client.all(:limit => 10) clients.each do |client| puts client.address.postcode end looks harmless but requires eleven sequential round-trips to the database. This version clients = Client.includes(:address).limit(10) clients.each do |client| puts client.address.postcode end still requires two, and one of the queries gets bigger as the number of ids increases. You can get into find_by_sql, but at that point ActiveRecord isn't adding any value.

rbranson 16y ago
Sure, but how many times have you seen someone create something equal to that with SQL queries? Instead of using a join, they execute a SELECT against the database for every row they fetch. This is shockingly common in horribly written PHP code. In addition, ActiveRecord also supports joins instead of using includes. Includes is almost always fine, unless the initial result set is large (100+ rows).
- chrisbolt 16y ago
  At least with SQL, it's obvious and not hidden by a layer of abstraction.

klochner 16y ago

You will definitely need to profile/optimize and hand code some queries. I ran into a bad one a while back (2.2.2): @foo = Foo.create @bars = Bar.find_all_by_some_attribute(:a) @foo.bars = @bars #--> slow! http://kevinlochner.com/rails-performance-inefficiencies http://kevinlochner.com/rails-performance-inefficiencies