Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Apply rules concurrently #44

Open
lqi opened this issue Jun 1, 2013 · 3 comments
Open

Apply rules concurrently #44

lqi opened this issue Jun 1, 2013 · 3 comments

Comments

@lqi
Copy link
Contributor

lqi commented Jun 1, 2013

We would like to have the option to apply rules concurrently against translation units. This should be able to improve the performance largely.

@lqi lqi closed this as completed Jun 1, 2013
@lqi lqi reopened this Jun 1, 2013
@nschum
Copy link
Contributor

nschum commented Aug 24, 2013

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
Copy link
Contributor

nschum commented Aug 24, 2013

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).

@nschum nschum mentioned this issue Aug 26, 2013
@lqi
Copy link
Contributor Author

lqi commented Aug 28, 2013

@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.

@ryuichi-assistant ryuichi-assistant removed this from the 0.9 milestone Jul 13, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants