[ruby-core:26958] Re: Caching #to_s for immutables (and a possible future for constant-folding) [with patch]

   The attached patch add caching of #to_s results to the main immutable 
classes in MRI Ruby core.  It requires that callers assume that #to_s 
may return a frozen String, if the receiver is not already a String. 
The semantic change is the source of the improvement.  It should be easy 
to back-port to 1.8.

   It returns frozen Strings for nil.to_s, true.to_s, and false.to_s. 
Float#to_s, Rational#to_s and Complex#to_s use a @to_s instance variable 
to cache the value for the lifetime of the receiver.  These methods can 
be changed to use an external hash table.  Fixnum#to_s and Bignum#to_s 
use an external hash table because they have a radix option.  I'm not 
convinced that the Fixnum#to_s cache is useful in real practice.

   The hash tables are fixed to 255 entries; I have not experimentally 
tuned them.  The hash function is quick but is likely to be sub-optimal.

   Rational#to_s and Complex#to_s assumed that #to_s returned a mutable 
String.  That was changed to build up from an empty String.  Those 
methods could probably be improved but I'm not sure if dup'ing is faster 
or slower.


Overall the patch should make:

   puts :'foo bar'; str << :'baz'

more space- and time-efficient than:

   puts 'foo bar'; str << 'baz'

since all String literals create garbage and Symbol#to_s is now a no-op.

   This technique could be easily be extended to cache #inspect if we 
adopt the rule "#inspect may return a frozen String."

   Could also cache Float, Bignum, Rational, and Complex construction 
using the same hash tables with very little effort.

Roger Pack wrote:
>>  It reduces the number of #to_s Strings created during the MRI test suite
>> for NilClass, TrueClass, FalseClass, Symbol and Float objects by 1890
>> Strings.
> 
> Sounds like it has potential, especially for long-lived constants and
> for symbols, which themselves are never collected anyway.
> 
Symbol already had a frozen cached String; the patch to Symbol#to_s 
removes the duplication of it.  (Why aren't IDs just Symbol VALUES? The 
Symbol code in parse.y seems really crufty.  Is it a bootstrapping 
issue?  Do Symbols really need to be that closely tied to the parser?)

> Perhaps adding an Object#to_s_nonfrozen would be convenient?
> 
The attached patch aliases the old #to_s methods as #to_s_new.

> Also do you have any benchmarks showing improvement? 
Yes.  The MRI test suite runs at 45 sec with these changes and at 53 sec 
without.  The MRI tests pass with no issues.  There is a naive test in 
the attached patch that demonstrates the improvements.

>Does it break rails?
I don't know yet.  I need to setup a proper Rails test environment.
There maybe some native thread issues with the cache hash tables, but I 
did start adding a mutex to each one.  I have not tested on 64-bit or 
anything other that Ubunutu 9.10.

See http://github.com/kstephens/ruby/commits/to_s_maybe_frozen/ for more 
details.

> -r
> 

Thanks,
Kurt Stephens
http://kurtstephens.com