Hi,
On Sat, Feb 21, 2015 at 11:46 PM, Thierry Goubier <thierry.goubier(a)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(a)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"