Our website uses cookies to enhance your browsing experience.
Your message has been sent. We will email you at
If you haven't received our response, please do the following:
check your Spam/Junk folder and click the
"Not Spam" button for our message.
This way, you won't miss messages from our team in the future.
Included into the set of standard preinstalled programs in the Windows 8 operating system, the Microsoft corporation for the first time ships their own antivirus called Windows Defender. Windows Defender actually came included into this set in earlier Windows versions too, but it served as an antispyware and malware filter only. But its latest incarnation under Windows 8 in fact integrates the free antivirus called Microsoft Security Essentials which was available for free download but wasn't integrated into previous Windows versions by default.
When running with Microsoft Security Essentials/Windows Defender active antivirus, PVS-Studio may show a significant slowdown when checking C/C++ files, depending on the analysis settings and user configuration. Before starting the static analysis process itself, PVS-Studio.exe calls the external preprocessor for each of the source-code files to get a full intermediate preprocessed file, i.e. a C/C++ file including header files with expanded macros. In the Visual Studio environment, PVS-Studio can use both the native Visual C++ preprocessor cl.exe and the third-party clang.exe preprocessor shipped inside the PVS-Studio distribution. It is when using cl.exe as the preprocessor that an issue occurs. We've already posted a report on this issue to Microsoft Visual C++ support.
In particular, when using the native Visual C++ cl.exe compiler as the preprocessor on a multi-core computer (when analysis runs in several concurrent threads for several files simultaneously), we can see an induced restriction (imposed by MSE/Windows Defender, as I suspect) on CPU resource usage of total 25% which is imposed for all the cl.exe processes. What does it mean in practice? When utilizing, for instance, 4 of cl.exe processes on a 4-core computer, the maximum total load of these processes doesn't exceed 25%, i.e. each one of them will get only about 6% of CPU execution time. But we are expecting that each one of these processes should get 25% of CPU time (when there's no background CPU load, of course)! It's clear that such a slow-down of each cl.exe will cause a significant increase of analysis time for each file being checked. Our experiments have shown that this 25% restriction doesn't relate to the number of cores in the system: we observed the same 1/4 performance restriction, working on an 8-core computer, and even binding cl.exe processes to different cores didn't change anything.
In the general case, we recommend that you always should add both the analyzer unit itself (PVS-Studio.exe) and all the software utilizing it, as well as their corresponding paths (for example, devenv.exe - the main executable of the Visual Studio environment), into the antivirus's exceptions list, when running PVS-Studio static analyzer under active antivirus software. Unfortunately, adding PVS-Studio.exe (as well as devenv.exe, cmd.exe and even cl.exe itself) into MSE/Windows Defender's exceptions list or even disabling the real-time protection don't fix the issue of performance loss with the cl.exe preprocessor. Only completely disabling MSE/Windows Defender (or replacing it with a different antivirus) allows you to use 100% of CPU resources for the preprocessing purpose.
So, the question arises: how does the build of Visual C++ projects progress when using the same cl.exe directly from the Visual Studio environment? For the build to run in parallel, i.e. to have several cl.exe processes run simultaneously, you need a solution containing at least several projects. An ordinary test build of such a solution (containing 87 of Visual C++ 10.0 projects) didn't reveal any performance issues at first sight. However, adding the compilation flags /P and /c to the properties for each of these projects (i.e. for preprocessing a file into an i file without linking) had actually caused the issue described above: 8 cl.exe processes were running under 2-3% of processor load each; that is, the total CPU load didn't exceed 25% again. Thus, this proves that the performance degradation with the Visual C++ preprocessor launched together with the MSE/Windows Defender doesn't depend on how it is started and whether it is launched from the PVS-Studio analyzer, the Visual Studio environment, or even manually from a cmd file. We can only suppose that when the preprocessing mode is enabled, cl.exe generates and actively writes to the intermediate i file on the hard disk, and the antivirus doesn't like it for some reason.
0
0
0
0