Apply rules concurrently about oclint

[nschum]

I've just played around with this a bit, but I was only able to get modest gains by parallelizing the rules.
For my sample app, just 25% of the time is spent applying the rules, but 75% of time is spent compiling.

I think it would be a lot more worthwhile to have one thread per file (including compilation) rather than per rule.
The downside is that, for full effect, the rules would either need to be thread-safe or each rule must be instantiated once per thread.

Experiment results

MacBook Pro 4x2.4 GHz (late 2011)
TotalFiles=94 FilesWithViolations=48 P1=0 P2=10 P3=127
5000 LOC, plus a bunch of CocoaPods dependencies

linear

• spike CPU usage: 100%
• wall time: 1:07
• CPU time: 1:02

rules parallel (8 threads)

• spike CPU usage: 160%-170%
• wall time: 0:53
• CPU time: 1:16

files parallel (8 threads)

• spike CPU usage: 700%
• wall time: 0:23
• CPU time: 1:44

[nschum]

Interestingly, dogfooding.sh actually fared much better with 2:43, 1:37, 1:16 wall time...
My sample project has a big prefix header. While this keeps compile times low in Xcode (where it is precompiled), it might have a negative effect on oclint (where it probably isn't).

[lqi]

@nschum, your observation is quite right. Currently, the performance bottleneck is the compilation time rather than the analysis time (unless the users have a huge rule set, but this is hardly true for now).

But in the future, when we have more rules and certain rules will require heavy analysis, so eventually the analysis time will be prominent.

I have taken a look at your pull request briefly, as always, very impressive quality code in high standard. Thank you for the help. I will get back to you in detail later.