Skip to content

Commit 2d6dc91

Browse files
authored
fixed #12516 - added a preliminary tuning guide [skip ci] (danmar#6632)
1 parent e76ec8d commit 2d6dc91

File tree

1 file changed

+153
-0
lines changed

1 file changed

+153
-0
lines changed

TUNING.md

Lines changed: 153 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,153 @@
1+
# Tuning Cppcheck Analysis
2+
3+
There are several ways you can potentially improve the runtime of a Cppcheck analysis.
4+
5+
Note: Most of these suggestions highly depend on your code base so they need to be evaluated before being applied. They might also depend the code of Cppcheck itself and your environment. So you might want to evaluate these on a regular basis.
6+
7+
## Collecting Information
8+
9+
To see the time each file took to analyze just specify the `--showtime=file-total` CLI option.
10+
11+
## Tuning At Build-Level
12+
13+
It is most likely that a pre-built binary is being used - either an official one or one provided by the packaging manager of my operating system.
14+
15+
But if you build your own binary it is possible to apply several steps to potentially improve the performance.
16+
17+
Note: Recently more distribution have opted to use more advanced optimization for their packages so several of the following suggestions might have already been applied.
18+
Please refer to the documentation of your distribution for more insight on this.
19+
20+
### Use Matchcompiler
21+
22+
(TODO: document how to use it when using the in-tree Visual Studio project)
23+
(TODO: check with a CMake generated Visual Studio project)
24+
25+
### Use Boost
26+
27+
Boost.Container (https://www.boost.org/doc/libs/release/libs/container) is being used for some containers which have a smaller overhead.
28+
29+
As the used library is header-only implementation you only need to install the package on the system you build the binary on but not on the system you run the analysis on.
30+
31+
The official Windows binary is currently not using this (TODO: file ticket).
32+
33+
(TODO: enable usage by default / bail out when it is enforced)
34+
35+
### Use A Different Compiler
36+
37+
Analyzing our own code base has shown that using a different compiler might lead to slightly better performance.
38+
39+
In our case Clang is mostly faster than GCC. See https://trac.cppcheck.net/ticket/10778 for some details.
40+
41+
### Use More Advanced Optimizations
42+
43+
By default we enforce the `-O2` optimization level. Even when using the `Release` build type in CMake which defaults to `-O3`. It might be possible that building with `-O3` might yield a perfomance increase.
44+
45+
There are also no additional code generation flags provided so the resulting binary can run on any system. You might be able to tune this and apply more optimization which is tailored to the system you will be running the binary on.
46+
47+
Needs to be evaluated. (TODO: file tickets)
48+
49+
### Use LTO
50+
51+
Needs to be evaluated. See https://trac.cppcheck.net/ticket/11671.
52+
53+
### Use profile-guided optimizations (PGO/BOLT/AutoFDO/Propeller)
54+
55+
Needs to be evaluated. See https://trac.cppcheck.net/ticket/11672.
56+
57+
## Tuning At Analysis-Level
58+
59+
### Use A More Performant Platform
60+
61+
It seems people assume that you need to run the analysis on the same system you build your code on/for. That is not necessary as the analysis is system-agnostic.
62+
As system headers are not required for analyzing your code you only need to specify the configuration which matches the system you run your code on.
63+
64+
In case you are using a project as input which can only be generated on the build/target system you can just transfer that to a different system and still run the analysis.
65+
66+
### Specify A Build Dir
67+
68+
Using the `--cppcheck-build-dir` allows you to perform incremental runs which omit files which have not been changed.
69+
70+
Important: As this is currently seriously lacking in testing coverage it might have shortcomings and need to be used with care. (TODO: file ticket)
71+
72+
### Exclude Static/Generated Files
73+
74+
If your code base contains files which rarely change (e.g. local copies of external dependencies) or you have generated files (e.g. `moc_*.cpp` for Qt projects) you might consider excluding these from the analysis.
75+
This can be done by using the `-i` option on the CLI, `<ignore>` in GUI projects or by including them to begin with into the files passed to the analysis.
76+
77+
Depending on your setup you might also consider to scan these files in a less frequent run (e.g. only when the files have changed or Cppcheck was updated).
78+
79+
This could also be handled using `--cppcheck-build-dir` (see above).
80+
81+
### Exclude System Headers
82+
83+
System headers are not necessary to perform the analysis. So you might consider not providing those to the analysis and specify a library configuration via `--library` instead.
84+
85+
`pkg-config` for instance will always provide non-system includes.
86+
87+
(TODO: file ticket about ignoring all braced includes)
88+
89+
### Limit The Configuration
90+
91+
By default configuration to analyze will be determined automatically for each file based on the code. The maximum amount is limited and can be controlled by CLI options.
92+
93+
Depending on your setup you might want to limit it to specific configuration by using `-D` (CLI) or `--project-configuration=` (Visual Studio project).
94+
When you are using a compilation database generated by CMake it is already using a fixed configuration.
95+
96+
### Use Multiple Jobs
97+
98+
By default only a single process/thread is being used. You might to scale this up using the `-j` CLI option. Please note that specifying a value that will max out your systems resources might have a detrimental effect.
99+
100+
### Use A Different Threading Model
101+
102+
When using multiple job for the analysis (see above) on Linux it will default to using processes. This is done so the analysis is not aborted prematurely aborted in case of a crash.
103+
Unfortunately it has overhead because of a suboptimal implementation and the fact that data needs to be transferred from the child processes to the main process.
104+
So if you do not require the additional safety you might want to switch to the usage of thread instead using `--executor=thread`.
105+
106+
Note: For Windows binaries we currently do not provide the possibility of using processes so this does not apply.
107+
108+
## Advanced Tuning
109+
110+
### Re-order The Files
111+
112+
Files which take longer to analyze should be processed at first so they might not extended the run time. As the order how the files provided on the CLI or via the project are being honored it is as simple as that.
113+
114+
### Adjust Thresholds
115+
116+
There are lots of internal thresholds which limit the work which is put into parts of the analysis. The defaults were chosen as a compromise of time being spent vs. issues being detected but not might not be a good fit in all cases.
117+
118+
These thresholds are currently neither exposed nor documented so they cannot be changed without the modifying the source which is *highly discouraged*.
119+
120+
They are being utilized internally by `-check-level` though (see below).
121+
122+
(TODO: file ticket about providing all bailouts)
123+
(TODO: file ticket about expose these)
124+
(TODO: file ticket about specifying these per file)
125+
126+
Note: As these will lead to less data being collected for the analysis it might lead to false negatives *and* false positives.
127+
128+
### Adjust Check Level
129+
130+
There are several check levels which are basically a collection of different threshold values (see above). This can be adjusted by the CLI option `--check-level`.
131+
132+
Note: The current default is the lowest available check level.
133+
134+
Note: As these will lead to less data being collected for the analysis it might lead to false negatives *and* false positives.
135+
136+
## Reporting Issues
137+
138+
If you encounter a file which has an unreasonable slow analysis please consider reporting this as an issue.
139+
140+
Also consider reporting major upticks in the runtime of the analysis after updating to a newer version. Some of these might be expected as the analysis is constantly improved but out-of-the-box we still need aim for reasonable times.
141+
142+
In all cases please try to provide a small reproducer if possible.
143+
144+
Note: There might even be cases the analysis will never finish because it is stuck in a cycle. This is quite uncommon but there are still several unresolved known cases so it is possible to encounter this.
145+
146+
### Known Issues
147+
148+
https://trac.cppcheck.net/ticket/10663
149+
https://trac.cppcheck.net/ticket/10765
150+
https://trac.cppcheck.net/ticket/10778
151+
https://trac.cppcheck.net/ticket/11262
152+
https://trac.cppcheck.net/ticket/12528
153+
https://trac.cppcheck.net/ticket/13698

0 commit comments

Comments
 (0)