On 25 March 2011 19:22, Mariano Martinez Peck <[email protected]> wrote: > > > On Fri, Mar 25, 2011 at 7:08 PM, Toon Verwaest <[email protected]> > wrote: >> >>>> What do you think? >>> >>> I am for... for the JIT is is a monomorphic send to a primitive, so the >>> IC will be very effective >>> and should take care that the lookup is actually almost never done. (and >>> the lookup is the >>> only thing the #class bytecode saves, as the target method is a >>> primitive). >> >> I think that programmers should have the illusion that the VM interacts >> with the system through message sends. By being able to overwrite this >> particular message you break this illusion. The VM will just fetch the real >> class; but the user doesn't get access to it anymore. Telling the system >> that this particular message shouldn't be overwritten is probably a good >> thing. >> >> If you want to overwrite the method class, maybe your tools should send >> another message than class in the first place? > > Of course I can do that. I can also do > > (ParseNode classVarNamed: 'StdSelectors') removeKey: #class ifAbsent: > []. > Compiler recompileAll. > > I don't care. I have it working for my "usage". This was just an example. > > And don't compare #class with all the boolean methods like #ifNil: and > friends or the bytecodes for integer operations....I think #class is sent > far less times than those... >
Yes. and i predict that performance impact in macro benchmarks, where you running normal code (which not sending this message intentionally in a loop) will be at the noise level magnitude. > >> >> I do however agree that many other optimizations become slightly >> superfluous, such as bytecodes for integer operations ... that somehow seems >> like compile-time inline-cached behavior without the ability to flush the >> cache :) >> >> cheers, >> Toon >> > > -- Best regards, Igor Stasenko AKA sig.
