2013/11/20 Eliot Miranda <eliot.miranda@gmail.com>

On Wed, Nov 20, 2013 at 8:47 AM, Nicolas Cellier <nicolas.cellier.aka.nice@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.

Nice idea. I've never liked this dynamic dispatch with string/symbol manipulation in Opal.

I added your fix in Opal on my computer right now, I put the optimized dictionary in a class variable. I will check with Marcus tomorrow if he's fine with it we will add it in Pharo 3.0 in the next few days.

However I didn't see compilation time being faster, I guess the performance improvement is not noticeable in the whole image recompilation time.

�

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@gmail.com>

On 19 November 2013 16:20, Marcus Denker <marcus.denker@inria.fr> wrote:

On 19 Nov 2013, at 16:07, Sven Van Caekenberghe <sven@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