I just have seen that there is a -j <jobs></jobs> option that "Start <jobs>
threads to do the checking simultaneously</jobs>" but it seems not working on
v1.89, indeed, for a same cppcheck command, when I run without -j option
it took 3 minutes 25 seconds (command run under Linux with preceding time
command, like time cppcheck <files> <options></options></files>), and when I run the same
command adding -j 14 (I have 16 cores, just want to keep 2 free for other
stuff), it took the same time and when I run htop on another terminal I
can see there is only one core working for cppcheck command.
It analyzes each TU separately in 1 core. So if you only have 1 TU then -j does not help. If you have 100 TUs then you should have got 14 cores for the analysis.
If you have many TUs and get 1 core then something seems to be wrong.. can you please tell us what compiler/os you're using?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
-j is used to analyze files in parallel. So if there is only one file to analyze it does not speed up anything as far as I know.
Did you analyze a project with many files or just one or a few files?
There are different implementations for Windows and Linux, but they should behave in the same way (For the user there should not be a difference). Under Cygwin there were severe issues with the Linux implementation (using fork) so we had to disable it here. If you try -j 2 under Cygwin it will directly print an error. What OS do you use?
Edit: I wrote at the same time as Daniel :) I also meant TU when I wrote "files".
Last edit: versat 2019-12-09
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
TU="Translation Unit"
If you scan a folder recursively that has 100 cpp files then there are 100 TUs. If you just tell Cppcheck to scan 1 file then -j does not help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I just have seen that there is a -j <jobs></jobs> option that "Start <jobs>
threads to do the checking simultaneously</jobs>" but it seems not working on
v1.89, indeed, for a same cppcheck command, when I run without -j option
it took 3 minutes 25 seconds (command run under Linux with preceding time
command, like time cppcheck <files> <options></options></files>), and when I run the same
command adding -j 14 (I have 16 cores, just want to keep 2 free for other
stuff), it took the same time and when I run htop on another terminal I
can see there is only one core working for cppcheck command.
Is there something I'm missing with this option ?
Thanks
It analyzes each TU separately in 1 core. So if you only have 1 TU then -j does not help. If you have 100 TUs then you should have got 14 cores for the analysis.
If you have many TUs and get 1 core then something seems to be wrong.. can you please tell us what compiler/os you're using?
-jis used to analyze files in parallel. So if there is only one file to analyze it does not speed up anything as far as I know.Did you analyze a project with many files or just one or a few files?
There are different implementations for Windows and Linux, but they should behave in the same way (For the user there should not be a difference). Under Cygwin there were severe issues with the Linux implementation (using
fork) so we had to disable it here. If you try-j 2under Cygwin it will directly print an error. What OS do you use?Edit: I wrote at the same time as Daniel :) I also meant TU when I wrote "files".
Last edit: versat 2019-12-09
TU="Translation Unit"
If you scan a folder recursively that has 100 cpp files then there are 100 TUs. If you just tell Cppcheck to scan 1 file then -j does not help.