[Pharo-dev] Tuning Opal Optimizations

Sven Van Caekenberghe sven at stfx.eu
Wed Nov 20 14:33:48 EST 2013


On 20 Nov 2013, at 18:53, Eliot Miranda <eliot.miranda at gmail.com> wrote:

> 
> 
> 
> 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 don’t get the ‘because the Dictionary will be precomputed’ in the code example you give. On the contrary, you will create a new Dictionary every time you execute your example, no ?

> 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





More information about the Pharo-dev mailing list