As I see it, there is around a hundred kBytes gain overall, maybe more in a production image full of add-on classes. Not that much nowadays, but since we cannot remove the complexity, it's still worth to select the selectors with most references. 2013/9/4 Igor Stasenko <siguctua@gmail.com>
i think you can feel the difference while running interpreter. With JIT it makes little sense to have special selectors imo.
On 4 September 2013 12:31, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
Agree, My point was to ensure there was no speedup, so it's only a space optimization (1 slot saved from literals, times 5000 senders or so per selector plus maybe a byte for the send bytecode ?). However the arithmetic ops, comparisons, bit ops, at: at:put:, == and class special selectors still have some specific speed up, especially in COG, so we cannot get rid of specialSelectors alltogether...
2013/9/4 Marcus Denker <marcus.denker@inria.fr>
On Sep 4, 2013, at 12:08 AM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
I note that #class was removed from specialSelectors (nilled entry) so as to not use the VM hack which fetches the class without sending a message. Pharo prefers the regular message send. But next to that entry, there is #blockCopy: which was formerly used for blue book BlockContext. BlockContext was removed from Pharo... So that makes two available slots for optimizing most used (sent) messages... We might choose some candidates and test on some macro benchmark if ever that really makes a difference.
I am not sure if optimizations on that level make senseâ¦
Marcus
-- Best regards, Igor Stasenko.