Re: [Parseperl-discuss] Performance hacks
Brought to you by:
adamkennedy
From: Adam K. <ad...@ph...> - 2006-07-20 05:59:25
|
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. 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. 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'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. 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. 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? Adam K Chris Dolan wrote: > The Perl::Critic team has been working on some performance > improvements, some of which rely on caching PPI information. If you > have created any PPI performance hacks, we'd love to hear about them, > either on this list or on de...@pe... (subscribe via > http://perlcritic.tigris.org/servlets/ProjectMailingListList) > > To see our accomplishments to date, take a look at (for example): > > PPI::Document::find() caching > http://perlcritic.tigris.org/source/browse/perlcritic/trunk/Perl- > Critic/lib/Perl/Critic/Document.pm?rev=527&view=markup > > PPI::Node::content() caching > http://perlcritic.tigris.org/servlets/ReadMsg?list=dev&msgNo=464 > > Chris > > -- > Chris Dolan, Software Developer, http://www.chrisdolan.net/ > Public key: http://www.chrisdolan.net/public.key > vCard: http://www.chrisdolan.net/ChrisDolan.vcf > > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Parseperl-discuss mailing list > Par...@li... > https://lists.sourceforge.net/lists/listinfo/parseperl-discuss |