Feature #16150


Add a way to request a frozen string from to_s

Added by headius (Charles Nutter) about 2 years ago. Updated about 1 year ago.

Target version:


Much of the time when a user calls to_s, they are just looking for a simple string representation to display or to interpolate into another string. In my brief exploration, the result of to_s is rarely mutated directly.

It seems that we could save a lot of objects by providing a way to explicitly request a frozen string.

For purposes of discussion I will call this to_frozen_string, which is a terrible name.

This would reduce string allocations dramatically when applied to many common to_s calls:

  • Symbol#to_frozen_string could always return the same cached String representation. This method is heavily used by almost all Ruby code that intermingles Symbols and Strings.
  • nil, true, false, and any other singleton values in the system could similarly cache and return the same String object.
  • The strings coming from core types could also be in the fstring cache and deduplicated as a result.
  • User-provided to_s implementations could opt-in to caching and returning the same frozen String object when the author knows that the result will always be the same.

A few ideas for what to call this:

  • to_fstring or fstring reflects internal the "fstring" cache but is perhaps not obvious for most users.
  • to_s(frozen: true) is clean but there will be many cases when the kwargs hash doesn't get eliminated, making matters worse.
  • def to_s(frozen = false) would be mostly free but may not be compatible with existing to_s params (like Integer#to_s(radix)

This idea was inspired by schneems (Richard Schneeman)'s talk at RubyConf Thailand, where he showed significant overhead in ActiveRecord from Symbol#to_s allocation.

Related issues

Related to Ruby master - Feature #16153: eventually_frozen flag to gradually phase-in frozen stringsOpenActions

Also available in: Atom PDF