Well, in fact, the issue aint that simple: thisContext
can be a quite expensive operation, compared to like a message send.
In Visualworks Smalltalk, stack access is extermly expensive because it uses the native C-stack and thus any access to thisContext
must reify the entire C-Stack into causally connected Smalltalk objects. That is, for each C stack frame a Smalltalk object is to be created (including possible JIT deoptimization) and furthermore all changes to these objects must be reflected back to the C stack.
In Pharo (and Squeak, for that matter) it is less awkward, since it uses Smalltalk objects for the stack. But still the object pool which caches stack frames is flushed upon each call. (Yes, other than eg in Java, pooling objects does improve performance in Squeak ... welcome back to the 90ies :)