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