# An analysis of memory bloat in Active Record 5.2

DevFeed: [An analysis of memory bloat in Active Record 5.2](<https://devfeed.tech/articles/an-analysis-of-memory-bloat-in-active-record-5-2-41347.md>)

Original publisher: [Read original article](<https://samsaffron.com/archive/2018/06/01/an-analysis-of-memory-bloat-in-active-record-5-2>)

Author: Sam Saffron

Published: 2018-06-01T07:07:15Z

Content type: article

Language: en

Sources: [Sam Saffron](<https://devfeed.tech/sources/sam-saffron.md>)

Topics: [Ruby](<https://devfeed.tech/topics/ruby.md>), [Rails](<https://devfeed.tech/topics/rails.md>), [Code](<https://devfeed.tech/topics/code.md>)

Tags: [activerecord](<https://devfeed.tech/tags/activerecord.md>), [analysis](<https://devfeed.tech/tags/analysis.md>), [memory](<https://devfeed.tech/tags/memory.md>), [performance](<https://devfeed.tech/tags/performance.md>), [rails](<https://devfeed.tech/tags/rails.md>), [ruby](<https://devfeed.tech/tags/ruby.md>)

## AI overview

An analysis of Active Record 5.2 argues that its object allocation and internal overhead can produce substantially higher memory usage and slower performance than raw database access. The article compares several Active Record approaches with a raw SQL implementation using allocation measurements.

## Source excerpt

One of the very noble goals of the Ruby community which is being spearheaded by Matz is the Ruby 3x3 plan. The idea is that using large amounts of modern optimizations we can make Ruby the interpreter 3 times faster. It is an ambitious goal, which is notable and inspiring. This "movement" has triggered quite a lot of interesting experiments in Ruby core, including a just-in-time compiler and action around reducing memory bloat out-of-the-box. If Ruby gets faster and uses less memory, then everyone gets free performance, which is exactly what we all want. A big problem though is that there is only so much magic a faster Ruby can achieve. A faster Ruby is not going to magically fix a "bubble sort" hiding deep in your code. Active Record has tons of internal waste that ought to be addressed which could lead to the vast majority of Ruby applications in the wild getting a lot faster. Rails is the largest consumer of Ruby after all and Rails is underpinned by Active Record. Sadly, Active Record performance has not gotten much better since the days of Rails 2, in fact in quite a few cases it got slower or a lot slower. Active Record is very wasteful I would like to start off with a tiny example: Say I have a typical 30 column table containing Topics. If I run the following, how much will Active Record allocate? a = [] Topic.limit(1000).each do |u| a << u.id end Total allocated: 3835288 bytes (26259 objects) Compare this to an equally inefficient "raw version". sql = -"select * from topics limit 1000" ActiveRecord::Base.connection.raw_connection.async_exec(sql).column_values(0) Total allocated: 8200 bytes (4 objects) This amount of waste is staggering, it translates to a deadly combo: Extreme levels of memory usage and Slower performance But .. that is really bad Active Record! An immediate gut reaction here is that I am "cheating" and writing "slow" Active Record code, and comparing it to mega optimized raw code. One could argue that I should write: a = [] Topic.select(:id