Major performance slowdown after updating

[BrandonHoffman]

Recently we upgraded from pylint 1.6.5 to the latest 1.8.4 and noticed a pretty significant slowdown when executing pylint -E over doubled out execution time from ~4 minutes to ~8.5 minutes

I did a little bit of benchmarking for all of the checks E**** by running pylint --disable =all --enable={code}

Below are the results for the checks which seemed to add a significant amount of time:

Code    1.6.5(s)        1.8.4(s)        diff(s)         perc    desc
==================================================================================================================================
E1101   20.1953449249   62.3351387978   42.1397938729   208      %s %r has no %r member
E1103   20.8538610935   61.1822810173   40.3284199238   193      %s %r has no %r member (but some types could not be inferred)
E1123   15.9687519073   40.2729401588   24.3041882515   152      Passing unexpected keyword argument %r in function call
E1102   14.8260128498   38.6876618862   23.8616490364   160      %s is not callable
E1124   15.3351070881   37.5729231834   22.2378160953   145      Parameter %r passed as both positional and keyword argument
E1120   15.7935380936   37.3748729229   21.5813348293   136      No value passed for parameter %s in function call
E1121   16.3191540241   37.6615300179   21.3423759938   130      Too many positional arguments for function call
E1111   18.251814127    37.993489027    19.7416749      108      Assigning to function call which doesn't return
E1201   11.5457539558   29.6404988766   18.0947449208   156      Logging format string ends in middle of conversion specifier
E1200   11.5785279274   29.4368979931   17.8583700657   154      Unsupported logging format character %r (%#02x) at index %d
E1206   12.1308939457   29.2484021187   17.117508173    141      Not enough arguments for logging format string
E1205   12.1985211372   28.7452499866   16.5467288494   135      Too many arguments for logging format string
E1305   10.8184630871   24.6197948456   13.8013317585   127      Too many arguments for format string
E1301   11.1120839119   24.4623908997   13.3503069878   120      Format string ends in middle of conversion specifier
E1310   11.0003929138   24.3273978233   13.3270049095   121      Suspicious argument in %s.%s call
E1300   11.0438139439   23.9392080307   12.8953940868   116      Unsupported format character %r (%#02x) at index %d
E1304   11.4094660282   23.6380119324   12.2285459042   107      Missing key %r in format string dictionary
E1306   11.319974184    23.4518930912   12.1319189072   107      Not enough arguments for format string
E1302   11.5838918686   23.6068780422   12.0229861736   103      Mixing named and unnamed conversion specifiers in format string
E1303   12.2280368805   23.2376339436   11.0095970631   90       Expected mapping for format string, not %s

for the times in the above table I removed the approximate time it takes to start up the pylint process with no checks enabled (pylint --disabled=all). This was to try and get as close as possible to the amount of time the check itself took to run.

[PCManticore]

Hey @BrandonHoffman Thanks for creating this issue!
This performance slowdown probably stems from the fact that between 1.6 and 1.8, we had better support for understanding Python in astroid, pylint's inference engine, which is used by these checks in one way or another. Admittedly, while understanding more Python leads to be more on spot error checking, it also leads to performance issues like this issue.
Also we started being more self-aware regarding the performance of pylint, and the next release will have some speed ups (not necessarily tied to these mentioned by you), such as pylint-dev/astroid#519 and pylint-dev/astroid#497.

[pzelnip]

FWIW, I did a bit of similar profiling on my project & looked at not all codes, but just the ones that currently were issues on our project. Of the 27 codes that our project currently violates, far and away the most expensive (~27 seconds to analyze vs 5-7 seconds for all others) was E1101 (no-member)

[PCManticore]

This most likely has been fixed in a similar vein to how we fixed #2198. Please give it a go to the recent 2.X release to make sure that it behaves in a fast manner on your codebase.