Hi,

On Sat, Feb 21, 2015 at 11:46 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Le 21/02/2015 23:18, Tudor Girba a écrit :
Hi,

On Sat, Feb 21, 2015 at 11:03 PM, Thierry Goubier
<thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote:

    Hi Doru,

    the low hanging fruit is the time needed to create a PP parser (time
    for new).


I still do not see the low hanging fruit. Do you have a concrete idea of
how to make it faster?

Look at that instantiation code, cache the result.
- Make a copy when you instantiate.
- Recreate / recompute if you execute a method extending the parser on the resulting object.
- Have a copy parser method which cleanly creates a new instance.

(i.e. summarized as: new should memoize and make a copy of the memoized version)

This would go against the understood meaning of new which should return a new instance, not a cached one.


Or look into reflection for making some methods trigger code generation, as if parser combinators were written in pragmas :)

I do not understand.



    I profiled PPSmalltalkParser over a bench used by Lucas Renggli a
    few years ago, and PPSmalltalkParser spends half the time in "new"
    (and it is a lot slower than it used to be).


What does "a lot slower" mean?

3 times slower in Pharo 4.
And this benchmark does not show any effect linked to long files; it's only a list of fairly short methods (all Object and Morph methods).


3 times slower comparing what to what? :) Is this the benchmark comparing a hand-written parser with the PPSmalltalkParser? If yes, where can we see it the code? If the benchmark is calling new multiple times, it is not particularly relevant.

Cheers,
Doru


--
www.tudorgirba.com

"Every thing has its own flow"