Yusuke ENDOH wrote:
> Hi,
> 
> 2009/12/1 Kurt Stephens <ks / kurtstephens.com>:
>>  I fixed issues uncovered by running make test-all.  There were a few tests
>> and modules that assumed Symbol#to_s was mutable -- #method_missing appears
>> to be a hot-bed for this assumption.  There were 7 common failures between
>> the patched code and the svn trunk:
>>
>> WITHOUT THE PATCH:
>>
>> real    5m19.335s
>> user    2m15.804s
>> sys     0m35.850s
>>
>> WITH THE PATCH:
>>
>> real    4m37.127s
>> user    1m51.243s
>> sys     0m33.454s
>>
>> Approx 14% faster.
> 
> 
> This is really interesting result, but the impact of the spec change seems
> not to be small.  I guess that it may be acceptable for Ruby 2.0, but NG
> for 1.8 and 1.9.
> 
> How about if #to_s returns, instead of a frozen String itself, a mutable
> String that is duplicated from the cached frozen String?  Become less
> effective than now?
> 

Another alternative would be to leave #to_s alone and introduce 
#to_s_maybe_frozen and change all the internals (IO methods, any_to_s, 
string interpolation) to use #to_s_maybe_frozen.  Others can adopt it as 
they please.

I don't think it we'll get the 15% improvement because 3rd party code 
wont get the improvement (but they wont get a runtime error either). 
The improvement comes from not creating garbage and constructing new 
objects unless necessary.

This is a pretty simple change, but I could use some help identifying 
how string interpolation is handled by the parser.

While were at it, I propose we add Object#dup_if_frozen to support 
things like:

   SOME_FROZEN_STRING = 'frozen string'.freeze
   SOME_STRING = 'string'
   def func_with_side_effects x
     x = x.to_s.dup_if_frozen
     x.sub!("str", "STR")
     x
   end
   func_with_side_effect SOME_FROZEN_STRING
   func_with_side_effect SOME_STRING

#dup_if_frozen should return self on immutables and immediates (Floats, 
Fixnums, Symbols, etc.)  This would make defining generic deep copy 
semantics much easier to write.

Kurt