From: James Tucker <jftucker@...>
Date: 2008-03-29T09:46:48+09:00
Subject: Re: Why Ruby do not optimize code at all?


On 29 Mar 2008, at 00:06, Eric Hodel wrote:
> On Mar 28, 2008, at 08:39 AM, James Tucker wrote:
>>>> Some optimization maybe affects debugging process.
>>>> Nevertheless, it seems "Constant folding" is not harmful but  
>>>> helpful.
>>>> I tried some pre-evaluation of constant or literal nodes in parsing
>>>> time.
>>
>> As said by others, open classes means parse time != run time, at all.
>>
>>>> Consider this code
>>>>
>>>> i = 320 * 200 * 32
>>
>> The only time I could see this being sensible to do is if it's  
>> actually closer to:
>>
>> A = 320.freeze
>> B = 200.freeze
>> C = 32.freeze
>>
>> i = A * B * C
>
> #freeze is not a solution to the constant folding optimizations.  It  
> only makes the object immutable, not it's class, and not its  
> instance_variables, so methods may be redefined on you anyhow, and  
> the contents of ivars may also change (String#replace, etc.)
>
>> However, the realistic implications are that freeze plus the  
>> discussed optimization causes a pre-processor fixed definition of  
>> the methods A.*() and B.*().
>>
>> In MRI, one can unfreeze too, so this still isn't "safe", and the  
>> source code does not resemble what is run.
>
> You can taint/untaint, but you cannot unfreeze.

Absolutely right, never use the thing, thanks for the correction.