From: "Florian Groß" <florgro@...>
Date: 2005-08-20T03:13:51+09:00
Subject: Re: Non-overridable and non-redefinable methods

Eric Mahurin wrote:

> Lately, I've been thinking about the future of ruby
> performance, ruby compilers, optimizations that a ruby compiler
> or VM could make, etc.  I've come to the conclusion that one
> big problem in ruby is that you can redefine (or remove) a
> method (of an object or an instance method of a class) at any
> point while running.  Here are the problem I see with being
> able to do this:

Or to say it in another way: The language is hard to optimize, let's 
change it to one that's easier to optimize at the cost of sacrificing 
features.

Note that this quote also applies here:

"Researchers seeking to improve performance should improve their 
compilers instead of compromising their languages."

-- An Efficient Implementation of SELF, a Dynamically-Typed 
Object-Oriented Language Based on Prototypes, July 1989

> To solve these problems and preserve existing functionality,
> I'd propose that there be a way to tag a method to not be
> redefinable or removable.

I'd propose doing it similar to YARV. Optimize 1 + 2, but only if you 
clearly see a Fixnum.freeze at the beginning of the file.

> Or am I off base?  Is there another way to get this kind of
> in-line performance without adding these
> non-overridable/non-redefinable capabilities.

It isn't easy which is why nobody has done it yet, but you can inline 
methods and heavily optimize them -- you just have to invalidate your 
optimized versions when a method has been changed. You can even compile 
two branches of the code -- one depending on no core class methods being 
overridden and the other not depending on it -- and execute the right 
one with an if statement.

The SELF guys have done a lot of interesting optimizations like this and 
I'd think that at least some of them can also be applied to Ruby.

The paper I quoted from: http://citeseer.ist.psu.edu/14611.html