powerman has asked for the wisdom of the Perl Monks concerning the following question:

I'd like to run perlcritic just like any other lint tool - each time I save file in Vim. But, truth is, perlcritic is too SLOW. It took about 1.5 seconds to check small file, and such delay on 'save file' operation isn't acceptable.

I've tried to use B::Bytecode compiler, including as much as possible modules used by perlcritic (381 modules, size of compiled file with bytecode ~240KB), but this doesn't make it faster at all.

I've also experimented with Devel::DProf, but at a glance there is no obvious bottlenecks, with a lot of luck there is a chance to quickly speedup it in 10-20% at most, which is surely not enough.

Last (actually, first) idea is to run perlcritic as client-server. This should save about 0.5-0.7 second, but ~0.8-1 second for checking file is still too slow.

I'm also think about limiting amount of tests executed by perlcritic by running it with -5 option while there are any errors found, and then run it with -4, -3, etc. This will speedup check when there are errors, but in case there is no errors (which is much more often) it actually will be slower because with -3 it will repeat already-done checks for -4 and -5. Also it have similar -top option, but using it actually make things slower.

With all these optimizations there is a chance to make it run in ~0.5 sec in _best_ case, which is probably more or less acceptable, but I'm afraid usually it won't be best case and it will take much longer to run.

So… any ideas how to speedup perlcritic to 0.3sec or less on average input?

Replies are listed 'Best First'.
Re: perlcritic speedup
by Anonymous Monk on Jan 24, 2012 at 14:25 UTC
    Replace DProf with Devel::NYTProf. Coordinate your optimisation work with the maintainers of P::C!

    Use the options -s or --only to run perlcritic in a staggered fashion as you describe, but without overlap in severity. See http://blog.jrock.us/posts/App::Persistent.pod and PPerl for implementations of the persistent server idea you describe.

[reply]
Re: perlcritic speedup
by jthalhammer (Friar) on Jan 25, 2012 at 06:16 UTC

    Perl::Critic has been through several rounds of optimizations, so I doubt you'll be able to squeeze much more performance out of it (but patches are always welcome).

    Most of the time is spent within PPI, parsing the file. So running a client/server arrangement won't help much. However, installing PPI::XS will give you a small speedup.

    Tuning your policy set might help some. Certain polices like like RequireTidyCode are considerably more intensive than others. Also, any policy that has 'PPI::Document' or 'PPI::Token::Word' in the applies_to method tends to be slower than other policies that have a more narrow focus. So if you can disable those policies (or just run them less often), then you might get a little better results.

    Editors like Komodo run Perl::Critic in the background as you edit the file, so you don't notice the performance as much. Perhaps you could get vim to do the same?

    Never mind folks that tell you when to save your files or how often to critique or syntax-check your code. Everyone has a different workflow. Do whatever works best for you.

    Jeffrey Thalhammer
    Imaginative Software Systems

[reply]

      Hmm. I was thinking about running perlcritic in background, but I didn't understood how this should work. Background perlcritic process will check some previous version of editing file, because I'll change it while perlcritic is running. So, when perlcritic will return it results, the line numbers in it output won't match current line numbers, some perlcritic messages won't be actual anymore, etc. This way perlcritic messages should confuse more than help.

      It probably possible to try to calculate differences between these two file versions, and fix perlcritic messages (at least line numbers) before showing them. But I don't sure this can be implemented in reliable way, to avoid showing non-actual anymore perlcritic messages.

[reply]
[reply]
Re: perlcritic speedup
by JavaFan (Canon) on Jan 24, 2012 at 21:21 UTC
    Think out of the box! Improve your coding style so you don't need to run perlcritic each time you save a file! Not only do you win 1.5 seconds each time you save a file, but you also save the time it takes to fix the issues perlcritic reports.
[reply]

      Thanks for your reply, but I didn't asked question you're replying to. I've asked how to speedup perlcritic, not is it make sense to use it.

      My coding style is very good, and you can easily examine it yourself by checking my modules on CPAN or my open source software on my website.

      So, I don't need perlcritic to improve my coding style. You probably know perl syntax good enough, but don't you find automated syntax check with perl -c on saving file very useful? We're all use it not because we don't know perl's syntax, but because it help us fix typos and mistakes early and easy. Same apply to use warnings and use strict. And same to perlcritic. They all help us have more safe and consistent coding style and warn about subtle issues at low cost and as early as possible.

      But perlcritic work in such a way, what if it wasn't used on regular basis all of time since you begin writing code, there is high chance first time you run perlcritic you got dozens, or, even more likely, hundreds of warnings. EVEN if your coding style is really very good. Some of these warnings probably should be disabled at all, some ignored with ## no critic, some just not really important but better to change code in way perlcritic wants to make code style more consistent, and, finally, few warn about very important subtle issues. And chances are when you notice these hundreds of warnings first time, you decide to move one and ignore them all, because task of handling them all looks too scary. THIS IS WHY I want to run perlcritic each time when saving file - to handle it's warnings one by one, instead of dozens at once.

[reply]
        but don't you find automated syntax check with perl -c on saving file very useful?
        Not at all. I want to save whenever I feel like it, and not whenever I think the syntax is correct. There are many times I save a file when running 'perl -c' on it would just sprout a gazillion of errors (because, you know, perl just can't shut up if there's one closing brace not typed yet)
[reply]

Back to Seekers of Perl Wisdom