Re: [Parseperl-discuss] Performance hacks

[Chris D. <ch...@ch...>]

On Jul 20, 2006, at 12:57 AM, Adam Kennedy wrote:

> Both of those look like fairly straight forward CPU vs memory  
> tradeoffs.
>
> Both assume the document is readonly (which PPI itself doesn't do)
> although that's fine in your case.

That's right.

> The second one is dangerous, because it assumes that ALL PPI document
> loaded in the entire process will always be readonly. It would be  
> unsafe
> if Perl::Critic was ever used in the same process as something that
> manipulated documents.

Agreed, which is why I didn't commit it to Perl::Critic.

> I think we might be able to make some trivial changes to make what you
> are doing a little safer though.
>
> Firstly, we could add a ->readonly flag to PPI::Document, which you
> would set with
>
> my $doc = PPI::Document->new( $something,
> 	readonly => 1,
> 	);

I was thinking something quite similar earlier today, but I couldn't  
think of a good way to implement it without either 1) sprinkling "if  
($self->top->readonly)" everywhere, or 2) multiple inheritance or  
mixin of a ::Mutable class for the non-readonly case.

> I've had this document syntax planned for some time now, so we  
> could do
> things like tabwidth => 8 and so on.
>
> What that would then allow you to do is to have some sort of a module
> that aggressively tweaks PPI's internals for the read-only case.  
> I'd be
> cool with you guys maintaining it, and then bundling it into the main
> PPI distribution.
>
> When this mode was enabled, the document constructor would refuse to
> create any document that didn't have ->readonly set to true, so  
> that the
> assumptions set by your optimisation hacks would be forced to hold  
> true.

Wait, are you suggesting a global readonly flag, or a per-instance  
readonly?  It sounds like the former.  I was instead thinking of the  
latter.

> This way, if you are running a dedicated perlcritic process, you can
> turn on ReadOnly mode and make perlcritic go faster, but in the  
> case you
> need to mix critic into some other program like an editor, it will  
> still
> work, just slower.

That certainly makes sense, whether global or per-instance.

> A simple technique is already used by PPI::XS, which overlays faster
> versions of several functions over the top of the default PPI ones.
>
> Further, if you happen to know a decent XS coder, get them to do some
> hacking on PPI::XS. The framework and backwards+forwards compatibility
> capability is already in place, we just need people to write faster
> versions of single functions.
>
> Between XS improvements, and a formalised ReadOnly mode, you should  
> have
> much much greater scope for writing more and more-varied  
> optimisations.
>
> How does that sound?

Great.  I'll play with PPI::XS.

Chris

--
Chris Dolan, Software Developer, http://www.chrisdolan.net/
Public key: http://www.chrisdolan.net/public.key
vCard: http://www.chrisdolan.net/ChrisDolan.vcf