How instance variables implemented?

Instance variables are implemented in terms of slots in an object body
which can be thought of as an array.  Generally, you have object bodies
look like this:

[instance variable slots][indexed slots]

The first chunk are instance variables ("named" indexed slots if you
will), the second chunk are the indexed slots accessed with
basicAt:/basicAt:put: and its siblings.

To avoid depending too much on the implementation details, use accessor
methods for the instance variables and always use the accessors to deal
with the instance variable values.

If you are interested, you might want to load the RBBytecodeTool parcel
and start looking at some methods (the parcel adds a panel in the
browser's code pane).

On 4/19/2011 9:19 PM, Rick Hedin wrote:
> How are instance variables implemented?  Are they looked up in a series
> of dictionaries like methods?  Do they depend on certain memory offsets
> like C++ objects?  Maybe I shouldn't write code depending on a
> particular implementation, but I find that not knowing how they are
> implemented is bothering me.
>               Regards,
>               Rick
>
> --
> I insist on rapport!
>
>
>

> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On Apr 19, 2011, at 9:42 PM, Rick Hedin wrote:

> Ah.  So after the method is "compiled" I assume all that's left is indices into this combined array.  Pretty fast.
>
> I assume accessor methods involve an ordinary lookup.  A dictionary access.  Not too bad, but the code I'm working on at the moment will be in front of the user's face all the time, and will be called often.  I'm probably better off referring to the instance variable by index.
>
> Thanks for the picture of what's going on.
>

I'm not entirely sure how you'd do that, but I would advise against it. There's lots of optimization and stuff that goes on; trying to short circuit it could backfire.

"Make it Work. Make it Right. Make it Fast."

I would make that your mantra always. The simplest system is the quickest to put together and the easiest to understand and the easiest to maintain. Only when you it works, and it works right, should you worry about "is this even fast enough." I've been doing Smalltalk and other things for 20 years now, and I've learned that lesson the hard way over and over again.

Because Smalltalk is such a "hands on" environment, you can actually do some testing yourself. You could test your hypothesis by doing something like this:

| ourObject |
ourObject := Point x: 4 y: 3.

"named access"
[100000000 timesRepeat: [ourObject x] ] timeToRun out.

"by index"
[100000000 timesRepeat: [ourObject instVarAt: 1] ] timeToRun out.

What I found for this version of VW on this platform is that the second is about 5x _slower_ than the first. My second warning about optimization is that you keep the knowledge you acquire when you do this kind of exploratory research, up to date. Over time, for various reasons, things change. Who knows, maybe someday instVarAt: will be super fast (but I doubt it).


--
Travis Griggs
Objologist
"The project was so plagued by politics and ego that when the engineers requested technical oversight, our manager hired a psychologist instead." -- Ron Avitzur

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc