Excessive redundant object allocation in AR

rubyonrails-core
1

Something that would work instead of a StringPool that is Ruby-ish is use of symbols. Symbols are Ruby’s answer to the StringPool. If things are stored as symbols, you can work with them similarly as to what you would expect and reduce # objects, e.g.

jruby-1.7.0.preview2 :008 > :error.object_id => 2050 jruby-1.7.0.preview2 :009 > :error.object_id => 2050 jruby-1.7.0.preview2 :010 > :error.to_s.chomp!(‘or’).to_sym => :err jruby-1.7.0.preview2 :011 > :error.to_s.chomp!(‘or’).to_sym.object_id => 2052 jruby-1.7.0.preview2 :012 > :error.to_s.chomp!(‘or’).to_sym.object_id => 2052

So basically if everywhere in Rails documentation that referred to strings instead specified constants, and if the method didn’t support constants that would be a good goal:

But still, whenever you output a string to a log, it becomes a string. So, you might be able to make some inroads by changes to Rails and related documentation, but if Ruby “fixed it” instead via something like StringPool (again- a major and breaking change), then you wouldn’t have to worry about wasting all that time on the Rails side.

In addition, many text editors and IDEs have different colors for Strings, so that keys and values stand out better in examples like:

class Employee < ActiveRecord::Base has_many :subordinates, :class_name => “Employee”, :foreign_key => “manager_id” belongs_to :manager, :class_name => “Employee” end

So, if you switch to all symbols, it is a little more monotone, colorwise. However, if you switch to Ruby 1.9 key/value then you could color the key in a: :b differently by the fact that it ends in a colon vs. starting with one. Unfortunately, the existing default color schemes don’t usually do that.

2

Symbols are never garbage collected in Ruby.

http://stackoverflow.com/questions/659755/ruby-symbols-are-not-garbage-collected-then-isnt-it-better-to-use-a-string

3

btw- I shouldn’t have said it like that. That makes it sound like symbols were invented as a reaction to Java’s StringPool. I just said this because the way you can continuously refer to a symbol and get the same object_id is similar to referring to a string that has been stored/retrieved from StringPool in Java.

4

Good point. However, for Rails, I’d think you’d still use less memory if symbols were just used for class, controller, model, field names in views, etc.

Even if Rails had to do handfuls (or 100s) of symbol → string → some change to string → to_sym’ing during startup, the memory consumption would very likely be less than not doing it.

You wouldn’t want to store every value retrieved from a database as a symbol obviously, nor store all values in incoming request params as symbols, and if things in Rails are doing regexp’s on something, it wouldn’t make sense to constantly be to_s’ing (in one way or another) to operate on them.

There is a balance between needing to garbage collect and needing to keep too many objects from being instantiated, even if they are GC’d. But you are right- the Java StringPool would GC something that was no long referenced, I believe, and if symbols are used for large varying strings, that’s a memory leak, but that’s not what I’m talking about.

5

Sorry, I meant if a large number of varying strings were symbols, that could be like a memory leak because of the lack of GC. (Just reword what I say to make sense. I need some caffeine.)