Any static code analyzer works slower than a compiler. It is determined by the fact that the compiler must work very quickly, though to the detriment of analysis depth. Static analyzers have to store the parse tree to be able to gather more information. Storing the parse tree increases memory consumption, while a lot of checks turn the tree traverse operation into a resource-intensive and slow process. Well, actually it all is not so much crucial, since analysis is a rarer operation than compilation and users can wait a bit. However, we always want our tools to work faster. The article contains tips on how to significantly increase PVS-Studio's speed.

1. Tips on speeding up PVS-Studio
Author: Evgeniy Ryzhkov
Date: 15.12.2011
This note is obsolete. Please read "Tips on speeding up PVS-Studio" in documentation.
Any static code analyzer works slower than a compiler. It is determined by the fact that the compiler
must work very quickly, though to the detriment of analysis depth. Static analyzers have to store the
parse tree to be able to gather more information. Storing the parse tree increases memory
consumption, while a lot of checks turn the tree traverse operation into a resource-intensive and slow
process. Well, actually it all is not so much crucial, since analysis is a rarer operation than compilation
and users can wait a bit. However, we always want our tools to work faster. The article contains tips on
how to significantly increase PVS-Studio's speed.
At first let's enumerate all the recommendations so that users learn right away how they can make the
analyzer work faster:
1. Use a multi-core computer with a large amount of memory.
2. Use an SSD both for the system and the project to be analyzed.
3. Configure (or turn off) your antivirus.
4. If possible, use Clang as the preprocessor instead of Visual C++ (it can be chosen in the PVS-
Studio settings).
5. Exclude libraries you don't need from analysis (can be set in the PVS-Studio settings).
Let's consider all these recommendations in detail, explaining why they allow the tool to work faster.
Use a multi-core computer with a large amount of memory.
PVS-Studio has been supporting multi-thread operation for a long time already (starting with version
3.00 released in 2009). Parallelization is performed at the file level. If analysis is run on four cores, the
tool is checking four files at a time. This level of parallelism enables you to get a significant performance
boost. Judging by our measurements, there is a marked difference between the four-thread and one-
thread analysis modes of test projects. One-thread analysis takes 3 hours and 11 minutes, while four-
thread analysis takes 1 hour and 11 minutes (these data were obtained on a four-core computer with 8
Gbytes of memory). That is, the difference is 2.7 times.
It is recommended that you have at least one Gbyte of memory for each analyzer's thread. Otherwise
(when there are many threads and little memory), the swap file will be used, which will slow down the
analysis process. If necessary, you may restrict the number of the analyzer's threads in the PVS-Studio
settings: Options -> Common Analyzer Settings -> Thread Count (documentation). By default, the
number of threads launched corresponds to the number of cores available in the system.
We recommend that you use a computer with four cores and eight Gbytes of memory or better.

2. Use an SSD both for the system and the project to be analyzed
Strange as it may seem, a slow hard disk is a bottleneck for the code analyzer's work. But we must
explain the mechanism of its work for you to understand why it is so. To analyze a file, the tool must first
preprocess it, i.e. expand all the #define's, include all the #include's and so on. The preprocessed file has
an average size of 10 Mbytes and is written on the disk into the project folder. Only then the analyzer
reads and parses it. The file's size is growing because of that very inclusion of the contents of the
#include-files read from the system folders.
I can't give exact results of measuring the influence of an SSD on the analysis speed because you have to
test absolutely identical computers with only hard disks different. But visually the speed-up is great.
Configure (or turn off) your antivirus
Judging by the character of its work, the analyzer is a complex and suspicious program from the
viewpoint of an antivirus. Let's specify right away that we don't mean that the analyzer is recognized as
a virus - we check this regularly. Besides, we use a code certificate signature. Let's go back to description
of the code analyzer's work.
For each file being analyzed a separate analyzer's process is run (the PVS-Studio.exe module). If a
project contains 3000 files, the same number of PVS-Studio.exe's instances will be launched. PVS-
Studio.exe calls Visual C++ environment variable setting (files vcvars*.bat) for its purposes. It also
creates a lot of preprocessed files (*.i) (one for each file being compiled) for the time of its work.
Auxiliary command (.cmd) files are being used.
Although all these actions are not a virus activity, it still makes any antivirus spend many resources on
meaningless check of the same things.
We recommend that you add the following exceptions in the antivirus's settings:
1. Do not scan system folders with Visual Studio:
a. C:Program Files (x86)Microsoft Visual Studio 8
b. C:Program Files (x86)Microsoft Visual Studio 9.0
c. C:Program Files (x86)Microsoft Visual Studio 10.0
d. etc.
2. Do not scan the PVS-Studio folder:
a. C:Program Files (x86)PVS-Studio
3. Do not scan the project folder:
a. For example, C:UsersUserNameDocumentsMyProject
4. Do not scan Visual Studio .exe files:
a. C:Program Files (x86)Microsoft Visual Studio 8Common7IDEdevenv.exe
b. C:Program Files (x86)Microsoft Visual Studio 9.0Common7IDEdevenv.exe
c. C:Program Files (x86)Microsoft Visual Studio 10.0Common7IDEdevenv.exe
d. etc.
5. Do not scan the cl.exe compiler's .exe files (of different versions):
a. C:Program Files (x86)Microsoft Visual Studio 8VCbincl.exe
b. C:Program Files (x86)Microsoft Visual Studio 8VCbinx86_amd64cl.exe
c. C:Program Files (x86)Microsoft Visual Studio 8VCbinamd64cl.exe
d. C:Program Files (x86)Microsoft Visual Studio 9.0VCbincl.exe
e. C:Program Files (x86)Microsoft Visual Studio 9.0VCbinx86_amd64cl.exe

3. f. C:Program Files (x86)Microsoft Visual Studio 9.0VCbinamd64cl.exe
g. C:Program Files (x86)Microsoft Visual Studio 10.0VCbincl.exe
h. C:Program Files (x86)Microsoft Visual Studio 10.0VCbinx86_amd64cl.exe
i. C:Program Files (x86)Microsoft Visual Studio 10.0VCbinamd64cl.exe
j. etc.
6. Do not scan PVS-Studio and Clang .exe files (of different versions):
a. C:Program Files (x86)PVS-Studiox86PVS-Studio.exe
b. C:Program Files (x86)PVS-Studiox86clang.exe
c. C:Program Files (x86)PVS-Studiox64PVS-Studio.exe
d. C:Program Files (x86)PVS-Studiox64clang.exe
Perhaps this list is too excessive but we give it in this complete form so that you know regardless of a
particular antivirus what files and processes do not need to be scanned.
Sometimes there can be no antivirus at all (for instance, on a computer intended specially to build code
and run a code analyzer). In this case the speed will be the highest. Even if you have specified the above
mentioned exceptions in your antivirus, it still will spend some time on scanning them.
Our test measurements show that an aggressive antivirus might slow down the code analyzer's work
twice or more.
If possible, use Clang as the preprocessor instead of Visual C++ (it can be
chosen in the PVS-Studio settings)
PVS-Studio exploits an external preprocessor. Earlier we used only one preprocessor by Microsoft Visual
C++. In PVS-Studio 4.50 we added support of another preprocessor Clang that works much faster and
doesn't have certain weak points of the Microsoft preprocessor (although it does have its own).
However, using the Clang preprocessor will in most cases make the analyzer's work faster 1.5-1.7 times.
But there is one thing you should remember. You may specify the preprocessor to be used in the PVS-
Studio settings: Options -> Common Analyzer Settings -> Preprocessor (documentation). There are three
alternatives available: VisualCPP, Clang and VisualCPPAfterClang. The first two are obvious. What the
third alternative is concerned, it means that Clang will be used first and if some errors occur during
preprocessing, the file will be then preprocessed again by Visual C++. It is this option
(VisualCPPAfterClang) which is chosen by default.
If your project is analyzed with Clang without any problems, you may use the default option
VisualCPPAfterClang or Clang - it doesn't matter. But if your project can be checked only with Visual C++,
you'd better specify this option so that the analyzer doesn't launch Clang in vain trying to preprocess
your files.
Exclude libraries you don't need from analysis (can be set in the PVS-
Studio settings)
Any large software project uses a lot of third-party libraries such as zlib, libjpeg, Boost, etc. Sometimes
these libraries are built separately, and in this case the main project has access only to the header and
library (lib) files. And sometimes libraries are integrated very firmly into a project and virtually become
part of it. In this case the main project is compiled together with the code files of these libraries.

4. The PVS-Studio analyzer can be set to not check code of third-party libraries: even if there are some
errors there, you most likely won't fix them. But if you exclude such folders from analysis, you can
significantly enhance the analysis speed in general.
It is also reasonable to exclude code that surely will not be changed for a long time from analysis.
To exclude some folders or separate files from analysis use the PVS-Studio settings -> Don't Check Files
(documentation).
To exclude folders you can specify in the folder list either one common folder like c:external-libs, or list
some of the folders: c:external-libszlib, c:external-libslibjpeg, etc. You can specify a full path, a
relative path or a mask. For example, you can just specify zlib and libjpeg in the folder list - this will be
automatically considered as a folder with mask *zlib* and *libjpeg*. To learn more, please see the
documentation.
Conclusion
Let's once again list the methods of speeding up PVS-Studio:
1. Use a multi-core computer with a large amount of memory.
2. Use an SSD both for the system and the project to be analyzed.
3. Configure (or turn off) your antivirus.
4. If possible, use Clang as the preprocessor instead of Visual C++ (it can be chosen in the PVS-
Studio settings).
5. Exclude libraries you don't need from analysis (can be set in the PVS-Studio settings).
The greatest effect can be achieved when applying all these recommendations simultaneously.