On Apr 8, 2005, at 11:05 AM, Avi Bryant wrote:

> Glenn Parker wrote:
>
>> There are also issues with using more memory than necessary if the
>> interpreter creates every instance variable the moment it is observed
> by
>> the compiler.
>
> Only in truly pathological cases - for normal numbers of instance
> variables, the overhead of an external lookup table would be higher
> than that of keeping a few unused slots in the body of the object.  But
> of course if the compiler saw that instances of a particular class
> might have up to 50 instance variables, it could choose to implement
> that class with a hashtable for variables.  I'm not convinced that case
> is likely enough to be worth checking and optimizing for,  but who
> knows.

Having your variables in a Hashtable is something I've heard of as a 
means of giving Java objects more reflective & dynamic capabilities.  
I've also done it as a quick and dirty way of storing Smalltalk objects 
as serialized files, but still being able to read the old ones even in 
after modifying their classes and adding instance variables.  (Which is 
not the right way to do it, but from an implementation standpoint is 
slightly quicker than the right way.)

However, when you do this, you are taking a *big* performance hit.  I 
suspect that this is one of the reasons why the Ruby VMs and the 
earlier Python VMs are so slow -- a trade-off has been made for 
programmer/VM-implementor convenience.  Alumina will maintain speed and 
programmer convenience in exchange for VM-implementor inconvenience.

--Peter


--
There's neither heaven nor hell, save what we grant ourselves.
There's neither fairness nor justice, save what we grant each other.