[Pharo-dev] Tuning Opal Optimizations

Eliot Miranda eliot.miranda at gmail.com
Wed Nov 20 12:53:06 EST 2013


On Wed, Nov 20, 2013 at 8:47 AM, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

> The only thing that annoyed me is that I failed to discover the
> incantation thru sender/implementor chain because some messages are
> constructed...
>

that's an anti-pattern to be avoided.  One can use dictionaries to make the
link explicit, then one has a chance of tracking things down.  Always use
something equivalent to

self perform:  (Dictionary newFromPairs: #(#timesRepeat:
#optimizeTimesRepeat: ...) at: message) with: ...

instead of

    self perform: ('compile', message) asSymbol with:

It'll be far clearer, and (cuz the dictionary will be precomputed) it'll be
faster too.

I tried the senders of timesRepeat: then the senders of corresponding
> visitor message (no image near my keyboard to check the name).
> Of course, once you've learned the incantation, it's OK...
>
>
> 2013/11/20 Igor Stasenko <siguctua at gmail.com>
>
>>
>>
>>
>> On 19 November 2013 16:20, Marcus Denker <marcus.denker at inria.fr> wrote:
>>
>>>
>>> On 19 Nov 2013, at 16:07, Sven Van Caekenberghe <sven at stfx.eu> wrote:
>>>
>>> > Hi,
>>> >
>>> > It seems that #timesRepeat: is compiled/optimized away by Opal, which
>>> is probably good. BTW, what is the list of selectors that get this
>>> treatment ?
>>> >
>>> RBMessageNode has #isInlined that returns true… not all cases where the
>>> selector is send it is optimised, so a list would be one of
>>> “possiblyoptimized” selectors…
>>> maybe #isInlined could check first against that list to quickly return
>>> false for all the other selectors.
>>>
>>> > In the PEGParser example of Xtreams #timesRepeat: is implemented for a
>>> non Integer class, which obviously leads to errors.
>>> >
>>> oh, yes, that is a problem. We started for ifTrue: to do an on-the-fly
>>> re-compiling and executing the ifTrue:, but it’s a bit of work to get it
>>> right for all cases… so we did not finish
>>> that. But it would be possible...
>>>
>>> > Is there a way to tune this ?
>>> > Can it be set at a level higher than in each method ?
>>> >
>>>
>>> Yes, you can do it per class-hierarchy… you can implement on the class
>>> side a method to parametrize the compiler:
>>>
>>> compiler
>>>         ^super compiler options: #(- optionInlineTimesRepeat)
>>>
>>>
>> .. and i feel really glad that Marcus armed my idea of option
>> specification e.g.
>>
>> #(+ optionToEnable1  - optionToDisable anotherOptionToDisable +
>> optionToEnable2 )
>>
>> :)
>>
>>
>>>         Marcus
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko.
>>
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20131120/d3a57cba/attachment-0002.html>


More information about the Pharo-dev mailing list