CppCheck 1.76.1 runs 35x slower in Virtual Machine
Static source code analysis tool for C and C++ code
Brought to you by:
danielmarjamaki
Menu
▾
▴
Hi all,
I am using CppCheck in a Windows 7 VMWare-VM to check a rather large codebase with several projects. Until recently, I used CppCheck 1.69. After an upgrade to the newest version, I noticed that the time needed for cppcheck to run has increased by a factor of ~35. But this is only true when I run it in the VM! Example: Running on one of the small projects with 26 files takes 250 seconds inside the VM and 7 seconds outside (also on Windows 7, on the exact same code and cppcheck executable). As a temporary solution, I downgraded to CppCheck 1.75. That takes 10 seconds in the VM and 5 outside (which is an expected and acceptable speed difference).
Does anyone have an idea where the problem might be? What I did notice: It seems CppCheck 1.76 no longer uses the four processor cores.
Greetings and thanks in advance,
mechjayti
Correction: 1.76.1 does use all the cores, but uses only 25% of the capacity, whereas 1.75 uses 100%. Bottleneck must be somewhere else.
It sounds like a VMWare issue. If you can give us a code snippet to reproduce, we can try to find out the bottleneck, however.
If you specify -j4, it will use four cores, however, the allocation works in the way that one core checks file A, one checks file B, and so on. So, if there is only a single file, it will use only one core, but it did so in 1.69 already (multithreading has always worked this way in cppcheck). That also means, if there is a single file that takes much longer than everything else, then in the end there will be just one thread working while all others are finished.
I just found the --showtime option, and that seems to reveal the culprit: Preprocessor::getcode takes very long in the VM (example: 1.071s in the VM, 0.011s on the PC). Comparing to 1.75, the getcode function is considerably faster in the older version (PC: 0.002s for the previous example). Whatever makes it slow, the same thing probably kills the performance on the VM, maybe due to limitations to the Shared Folder-Functionality in VMWare?