Freeze columns before using them as hash keys #7631

jeremyevans · 2012-09-13T21:14:15Z

This reduces the number of allocated strings from columns * (rows + 1) to just columns. This should fix #7629.

This reduces the number of allocated strings from columns * (rows + 1) to just columns.

rafaelfranca · 2012-09-13T21:16:38Z

Could you add benchmark to the commit message?

cc @tenderlove @jonleighton

jeremyevans · 2012-09-13T21:19:22Z

Why should I spend more time helping the competition? ;)

rafaelfranca · 2012-09-13T21:21:40Z

lol. Right. I just ask, we don't need to do. I'll not merge without @tenderlove and @jonleighton approval.

Also thank you for the pull request.

dmathieu · 2012-09-13T21:30:12Z

activerecord/lib/active_record/result.rb

@@ -11,7 +11,7 @@ class Result
    attr_reader :columns, :rows, :column_types

    def initialize(columns, rows, column_types = {})
-      @columns      = columns
+      @columns      = columns.map{|c| c.freeze}


master is only 1.9 compatible. So you can use columns.map(&:freeze)

cc @jeremyevans

@lunks, I saw that before you opened the pull request. Like I said, it's up to rails core to change the style after they merge it, if they even decide to merge it.

to change the style after they merge it,

Naw, style changes are always asked for before merging, not after. We actually don't do style-only commits.

Are the values in @columns actually used as Hash keys? If not always, then this change is actually worse than without it because this code always allocates another copy of each string and then freezes it. Basically, it's paying constant upfront cost instead of a variable cost. You'll need to just show why that trade off is valid.

@jeremyevans Oh yes yes. Just an extra Array. Ooops! I hadn't had dinner yet!

We can do @columns = columns.each(&:freeze) or @columns = columns.each {|c| c.freeze} to avoid allocating that extra array.

Tbh, I'd rather the thing that calls initialize do the freezing. Freezing strings does mutate them. People may not expect that we froze their strings.

Aaron Patterson
http://tenderlovemaking.com/
I'm on an iPhone so I apologize for top posting.

On Sep 14, 2012, at 8:14 PM, thedarkone notifications@github.com wrote:

In activerecord/lib/active_record/result.rb:

@@ -11,7 +11,7 @@ class Result
attr_reader :columns, :rows, :column_types

def initialize(columns, rows, column_types = {})

@columns = columns

@columns = columns.map{|c| c.freeze}
We can do @columns = columns.each(&:freeze) or @columns = columns.each {|c| c.freeze} to avoid allocating that extra array.

�
Reply to this email directly or view it on GitHub.

Perhaps it's better to dup, then freeze them?

That should work almost as well, since the Result isn't per returned instance.

wlipa · 2012-09-13T21:42:02Z

I verified this fix worked for the case I was studying in #7629, bringing the number of extra strings per AR model instance down from 15 to 2. Thanks!

rafaelfranca · 2012-09-13T23:21:33Z

@wlipa do you have to check this case that can be shared?

wlipa · 2012-09-13T23:33:47Z

Here's a two line check that relies on an AR model with more than one instance in the db.

  arr = MyModel.all # or any other AR query that returns > 1 of the same object type
  arr.first.instance_variable_get("@attributes").keys.first.object_id == arr.last.instance_variable_get("@attributes").keys.first.object_id

That will be true if the keys aren't getting duplicated.

(Note, this assumes that columns are always stored in the same order in the attributes hash. Not sure if that's a safe assumption. If not one could select the key named "id".)

fxn · 2012-09-13T23:39:20Z

While @tenderlove or @jonleighton say something... I'd like to suggest adding a comment. Without a comment the next guy reading that file will wonder why that is done.

tenderlove · 2012-09-14T01:21:45Z

Can we actually prove that this is a performance bottleneck before merging? "Many objects allocated" does not equal "slow system". Also, note that while we may be reducing memory here, we're also trading it for speed (extra method calls to freeze). Please, please, please someone make hard numbers and graphs before we embark on this micro-optimization hunt.

I am a hard 👎 on this pull request until someone can actually demonstrate a real performance increase.

wlipa · 2012-09-14T03:36:42Z

For this optimization, it shouldn't be necessary to call freeze more than N times per process where N is the number of db fields in AR classes (ie, a small constant cost at startup). That would probably change the patch though.

wlipa · 2012-09-14T03:52:47Z

@jeremyevans stated that Ruby internally dups and calls freeze on strings used as hash keys. Given that, this patch should substantially reduce the number of calls to freeze, simply because there are so many fewer strings in play.

That said I'll take a look at gathering some metrics. Never a bad idea!

wlipa · 2012-09-14T04:58:23Z

I took a more detailed look at an AR model with 9 integer fields, 2 datetimes, and 2 strings. Querying the full table out from my db with MyModel.all returned 9200 rows.

The growth in process resident set size after the query was 21m (from 84m to 105m) with the patch applied. Without the patch, the growth was 29m (from 87m to 116m). So the patch yielded at 27.5% reduction in process rss growth for this query.

The average CPU time to do the query was 1.16s patched and 1.22s unpatched, so 5% reduction there.

This was with Ruby 1.9.3p194, Ubuntu 12.04, and Rails 3.2.8.

steveklabnik · 2012-09-14T05:01:08Z

@wlipa could you provide the benchmark script, please?

wlipa · 2012-09-14T05:05:49Z

You mean "MyModel.all" with the database as described? It's really as simple as that.

tenderlove · 2012-09-14T06:23:24Z

What were the column names you used? How many times did you run the program? What was the std dev? Can you provide the code so that we can reproduce your results and add it to the benchmarks? Thanks!

Aaron Patterson
http://tenderlovemaking.com/
I'm on an iPhone so I apologize for top posting.

On Sep 14, 2012, at 1:58 PM, Bill Lipa notifications@github.com wrote:

I took a more detailed look at an AR model with 9 integer fields, 2 datetimes, and 2 strings. Querying the full table out my db with MyModel.all returned 9200 rows.

The growth in process resident set size after the query was 21m (from 84m to 105m) with the patch applied. Without the patch, the growth was 29m (from 87m to 116m). So the patch yielded at 27.5% reduction in process rss growth for this query.

The average CPU time to do the query was 1.16s patched and 1.22s unpatched, so 5% reduction there.

This was with Ruby 1.9.3p194, Ubuntu 12.04, and Rails 3.2.8.

�
Reply to this email directly or view it on GitHub.

thedarkone · 2012-09-14T11:26:16Z

Pre-freezing String keys before using them as keys in multiple Hash instances is a very cool optimisation that I myself frequently use. This should be merged.

wlipa · 2012-09-14T17:03:42Z

Here are instructions for replicating from scratch in a new app.

rails new querypig -d mysql
rails generate model MyModel user_id:integer kind:integer product_id:integer comment_id:integer duration:integer category_id:integer ip:string leaderboard_id:integer status_id:integer description:string
rake db:create db:migrate

Populate the database:

10000.times do
  MyModel.create({
    :user_id => rand(1..100),
    :kind => rand(1..100),
    :product_id => rand(1..100),
    :comment_id => rand(1..100),
    :duration => rand(1..100),
    :category_id => rand(1..100),
    :ip => rand(1..100).to_s,
    :leaderboard_id => rand(1..100),
    :status_id => rand(1..100),
    :description => rand(1..100).to_s,
  })
end

Measure the memory usage:

def resident_mb
  `ps -o rss= -p #{Process.pid}`.to_i / 1.kilobyte
end

def stats
  GC.start
  rmb = resident_mb
  puts "pid #{Process.pid} rss: #{rmb}m gc: #{GC.stat}"
  rmb
end


# preflight
MyModel.first

initial_rss = cur_rss = stats

8.times do 
  # potentially piggish
  mm = MyModel.all
  cur_rss = stats
end

puts "rss delta: #{cur_rss - initial_rss}"

I did that by sticking the above in script/measure.rb and using the command "rails runner script/measure.rb". On OSX I consistently got a delta of right near 18m with the patch, and a varying but always larger amount between 25-41m without it.

spastorino · 2012-09-20T04:13:46Z

I wonder why do adapters return strings instead of symbols.

NZKoz · 2012-09-20T04:23:29Z

As @jeremyevans points out, generating columns.size strings is considerably less GC pressure than columns.size * result_set.size. These strings are the keys to the attributes hash, so I don't think we need to worry about users expecting to be able to do something crazy like

  @attributes.keys.map(&:upcase!)

This seems like a complete no brainer to me, the only change I'd suggest is just interning the strings to symbols but that's something that could surprise users.

jeremyevans · 2012-09-20T04:31:07Z

Note that you can't upcase! hash string keys in ruby anyway, even if the string used as a key wasn't frozen:

$ ruby -e '{"a"=>1}.keys.map{|s| s.upcase!}' 
-e:1:in `upcase!': can't modify frozen String (RuntimeError)
        from -e:1:in `block in <main>'
        from -e:1:in `map'
        from -e:1:in `<main>'

This is because ruby uses a frozen dup of the string as the hash key if the string isn't already frozen, so pretty much all string hash keys in ruby are already frozen.

Freeze columns before using them as hash keys

spastorino · 2012-09-20T04:46:01Z

I've moved the code to hash_rows methods and added a comment 2068d30
Thanks @jeremyevans

wlipa · 2012-09-20T05:21:17Z

Doesn't that change it by calling @columns.map { |c| c.freeze } once per row rather than once per result?

spastorino · 2012-09-20T16:00:15Z

Ouch yeah sorry. Fixed da400fb

Freeze columns before using them as hash keys

3aef5ce

This reduces the number of allocated strings from columns * (rows + 1) to just columns.

jeremyevans closed this Sep 13, 2012

jeremyevans reopened this Sep 13, 2012

dmathieu reviewed Sep 13, 2012
View reviewed changes

argent-smith mentioned this pull request Sep 14, 2012

об оптимизации rubynoname/ShowNotes#33

Closed

tenderlove added a commit that referenced this pull request Sep 20, 2012

Merge pull request #7631 from jeremyevans/patch-1

2004ef2

Freeze columns before using them as hash keys

tenderlove merged commit 2004ef2 into rails:master Sep 20, 2012

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Freeze columns before using them as hash keys #7631

Freeze columns before using them as hash keys #7631

jeremyevans commented Sep 13, 2012

rafaelfranca commented Sep 13, 2012

jeremyevans commented Sep 13, 2012

rafaelfranca commented Sep 13, 2012

dmathieu Sep 13, 2012

lunks Sep 14, 2012

jeremyevans Sep 14, 2012

steveklabnik Sep 14, 2012

evanphx Sep 14, 2012

evanphx Sep 14, 2012

thedarkone Sep 14, 2012

tenderlove Sep 15, 2012

lunks Sep 15, 2012

wlipa Sep 15, 2012

wlipa commented Sep 13, 2012

rafaelfranca commented Sep 13, 2012

wlipa commented Sep 13, 2012

fxn commented Sep 13, 2012

tenderlove commented Sep 14, 2012

wlipa commented Sep 14, 2012

wlipa commented Sep 14, 2012

wlipa commented Sep 14, 2012

steveklabnik commented Sep 14, 2012

wlipa commented Sep 14, 2012

tenderlove commented Sep 14, 2012

thedarkone commented Sep 14, 2012

wlipa commented Sep 14, 2012

spastorino commented Sep 20, 2012

NZKoz commented Sep 20, 2012

jeremyevans commented Sep 20, 2012

spastorino commented Sep 20, 2012

wlipa commented Sep 20, 2012

spastorino commented Sep 20, 2012

Freeze columns before using them as hash keys #7631

Freeze columns before using them as hash keys #7631

Conversation

jeremyevans commented Sep 13, 2012

rafaelfranca commented Sep 13, 2012

jeremyevans commented Sep 13, 2012

rafaelfranca commented Sep 13, 2012

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wlipa commented Sep 13, 2012

rafaelfranca commented Sep 13, 2012

wlipa commented Sep 13, 2012

fxn commented Sep 13, 2012

tenderlove commented Sep 14, 2012

wlipa commented Sep 14, 2012

wlipa commented Sep 14, 2012

wlipa commented Sep 14, 2012

steveklabnik commented Sep 14, 2012

wlipa commented Sep 14, 2012

tenderlove commented Sep 14, 2012

thedarkone commented Sep 14, 2012

wlipa commented Sep 14, 2012

spastorino commented Sep 20, 2012

NZKoz commented Sep 20, 2012

jeremyevans commented Sep 20, 2012

spastorino commented Sep 20, 2012

wlipa commented Sep 20, 2012

spastorino commented Sep 20, 2012