[Pharo-dev] Tuning Opal Optimizations

Igor Stasenko siguctua at gmail.com
Wed Nov 20 09:36:38 EST 2013


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20131120/50a2c42f/attachment-0002.html>


More information about the Pharo-dev mailing list