[Pharo-project] Remove #class as a Compiler optimization
Hi. I have to say that I hate that the compiler associates a special bytecode for #class and that the VM don't even send the message. I want to be able to overwrite #class in a proxy for example, or to debug it. I did some benchmarks disabling such optimization by doing: (ParseNode classVarNamed: 'StdSelectors') removeKey: #class ifAbsent: []. Compiler recompileAll. And the difference is NOTHING in my tests (maybe I am doing something wrong). With Standard VM and #class optimization [SystemNavigation default allObjectsDo: [:each | each class]] timeToRun -> aprox 50 miliseconds With Standard VM and WITHOUT #class optimization [SystemNavigation default allObjectsDo: [:each | each class]] timeToRun -> aprox 60 miliseconds So...only 10 miliseconds more for asking the class to all the objects in the system.....(done in a PharoCore 1.3) With Cog VM and #class optimization [SystemNavigation default allObjectsDo: [:each | each class]] timeToRun -> aprox 13 miliseconds With Cog VM and WITHOUT #class optimization [SystemNavigation default allObjectsDo: [:each | each class]] timeToRun -> aprox 17 miliseconds So...only 5 miliseconds more for asking the class to all the objects in the system.....(done in a PharoCore 1.3) Considering (5 / 324535) asFloat 0,000015406... of overhead What do you think? Mariano
I am against non-transparent optimizations as well. However, I think special selectors like ifTrue: / class and so forth should still be used in the VM since its cheap way getting some performance improvements. But to make them work in a decent OO way they should also be able to deal with a non-standard implementation (like customized Boolean class). On 2011-03-25, at 17:26, Mariano Martinez Peck wrote:
Hi. I have to say that I hate that the compiler associates a special bytecode for #class and that the VM don't even send the message. I want to be able to overwrite #class in a proxy for example, or to debug it.
ObjectsDo: [:each | each class]] timeToRun -> aprox 17 miliseconds
So...only 5 miliseconds more for asking the class to all the objects in the system.....(done in a PharoCore 1.3)
Considering (5 ms / 324535) asFloat 0,000015406 ms... of overhead
Arguing with absolute values is a bit dangerous: But it makes 13ms / 17ms * 100% = 76% => 25% speed improvement! in COG 50ms / 60ms * 100% = 83% => 17% faster So the impact is still quite big. But indeed I would be in favor of a normal message send...
participants (2)
-
Camillo Bruni -
Mariano Martinez Peck