performance

[Daniel Marjamäki]

I plan to look at the performance of Cppcheck in the next couple of weeks.

I hope it will be possible to speedup the parser. For C code I think it should be possible to skip some expensive parsing - for instance the name lookups in setVarId and simplifyTypedef could be simplified.

But I also think it should be possible to limit analysis. If a file normally takes 10 minutes to scan and the user for example wants it to take just ~30 seconds.. then I would like to be able to be flexible and provide some analysis in 30 seconds also. That is still a very long time to a computer.

Firewave made a PR not long ago to skip the valueflow. I would think an option for that would also fit well.

I don't know how to configure this but do you have some opinions. Would it be a good idea to add some --performance= option.

[john borland]

I can't remember what was the last cppcheck version I flame graphed. From what I remember any any of the valve flow function that ended up calling updateRange had the highest run times. If you were looking to make a value flow lite option I would look there. When I ran the flame graphs on some of the Daca runs that were taking a lot of time to complete there was another path that looked odd to me, but I never got the time to look into it. If I get some time tomorrow I will run the flame graphs for the latest release and post them to this thread.

[john borland]

I have attached a tar file with all the svg files from the flame graphs that I have run on latest version of cppcheck 2.9.

This is the basics of the bash script I used. So you can see what code the flame graph is for.

singleRunFunc() {
   true # you can't have an empty funciton.
   echo $1
   date
   perf record -F 99 --output=$1.out.perf.data -g ./bin/cppcheck --library=posix --library=gnu  --showtime=top5 --check-library --inconclusive --enable=all --inline-suppr --template=daca2 -D__GNUC__ --platform=unix64 -rp=temp -j 1 $2 &> $1.out.out
   perf script --input=$1.out.perf.data > ./$1.out.perf
   ../../../FlameGraph/stackcollapse-perf.pl ./$1.out.perf > ./$1.out.folded
   ../../../FlameGraph/flamegraph.pl ./$1.out.folded > ./$1.svg
}
#-|
if [[ "${BASH_SOURCE[0]}" = "$0" ]]; then
   trap cleanup EXIT
   # Script goes here
   # ...
   #find ./ -maxdepth 6 -type d -name atlas -print0 | xargs -0 -n 1 -P 5 sub_stub
   #date +'%Y-%m-%d_%H_%M_%S'
   cd ./2.9/Build
   pwd

   singleRunFunc 2.9_astutils ../lib/astutils.cpp
   singleRunFunc 2.9_cppcheck ../lib/
   singleRunFunc 2.9_xf86 ../../Test/xf86-video-mach64-6.9.6
   singleRunFunc 2.9_freemat ../../Test/FreeMat-4.2-Source
   singleRunFunc 2.9_cloog ../../Test/cloog-0.18.4
   singleRunFunc 2.9_py-rapidjon ../../Test/python-rapidjson-1.4
   singleRunFunc 2.9_parted ../../Test/parted-3.5
   singleRunFunc 2.9_xbmc ../../Test/xbmc-13.2-Gotham
   singleRunFunc 2.9_ale ../../Test/ale-0.9.0.3
   singleRunFunc 2.9_gpac ../../Test/gpac-2.0.0
   singleRunFunc 2.9_moravm ../../Test/MoarVM-2022.04
   singleRunFunc 2.9_fontforge ../../Test/fontforge-20220308
   singleRunFunc 2.9_abPOA-1.4.1 ../../Test/abPOA-1.4.1
   singleRunFunc 2.9_aevol-5.0 ../../Test/aevol-5.0
   singleRunFunc 2.9_asymptote-2.82 ../../Test/asymptote-2.82
   singleRunFunc 2.9_jlint-3.0 ../../Test/jlint-3.0
   singleRunFunc 2.9_libstaroffice-0.0.7 ../../Test/libstaroffice-0.0.7
   singleRunFunc 2.9_tint2-v17.0.1 ../../Test/tint2-v17.0.1

   date
fi

This is how I build cppcheck

git clone https://github.com/brendangregg/FlameGraph.git
git clone https://github.com/danmar/cppcheck.git 2.9
cd cppcheck/
git checkout tags/2.9 -b 2.9
mkdir Build
cd Build
export CXXFLAGS="-g -fno-omit-frame-pointer"
cmake MATCHCOMPILER=YES -DCMAKE_BUILD_TYPE=Release ..
make -j 6 >& build.out.out

I haven't had too much time to look at the flame graphs yet, but I figure it was best to share them. I did seem some strange things in them, but need more time to look at them, but it still looks like most time is spent in the value flow set values part of the code base.