Speeding up pylint

Pylint runs for several minutes on my project; I'd like to add it to my CI build, but I'm not sure I want to introduce that much delay. Is there any trick to optimizing it? Are there some particularly slow inspections that I could disable?

On Mon, Dec 22, 2014 at 3:16 AM, Chris Martin <ch.martin@gmail.com> wrote:
Pylint runs for several minutes on my project; I'd like to add it to my CI build, but I'm not sure I want to introduce that much delay.
Is there any trick to optimizing it? Are there some particularly slow inspections that I could disable?
Hi, Maybe it's related to this issue: https://bitbucket.org/logilab/pylint/issue/395/horrible-performance-related-.... I didn't have that much time to take a look at it, but it's on my priority list for 1.4.1. The problem is not inspect-specific, but it's something fishy in the inference engine, which wasn't there before.

On Sun, Dec 21, 2014 at 7:16 PM, Chris Martin <ch.martin@gmail.com> wrote:
Pylint runs for several minutes on my project; I'd like to add it to my CI build, but I'm not sure I want to introduce that much delay.
Is there any trick to optimizing it? Are there some particularly slow inspections that I could disable?
I'll let others identify slower checks. I've never found pylint to be a big deal performance-wise, especially when compared to traditional compiled systems. (Perhaps you've never built large C++ systems?) Here are my thoughts: * If you find it useful, why disable something just because it's a bit slow? Would you prefer to miss possible problems in favor of running a bit faster? * Couldn't you just run pylint on the subset of files which have changed? * Are you running one massive pylint across all modules in your system? Perhaps break it into multiple runs on (possibly overlapping) subsets of the system which would either run faster one-by-one, or could be run in parallel. * Doesn't this stuff run off on its own while you're busy doing other things? Is it really holding you up, or is it just perception? My 2¢... Skip

On 12/22/14 10:37 AM, Skip Montanaro wrote:
* Couldn't you just run pylint on the subset of files which have changed?
BTW, diff-cover (https://github.com/edx/diff-cover) is a tool that runs pylint, pep8, and coverage on just your recent changes, rather than on the entire working tree resulting from your changes. This gives you an achievable goal (each patch should be clean) that can help move a messy project toward goodness in a satisfying way. --Ned.
participants (4)
-
Chris Martin
-
Claudiu Popa
-
Ned Batchelder
-
Skip Montanaro