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 :

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.



"Every thing has its own flow"