Last time. there was a release candidate for 2.5. Unfortunately, a number of regressions slipped in after the RC was announced. Maybe this can be avoided this time around.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
yes I'd hope we can create a RC in ~ 2-4 weeks when most of the crashes have been fixed. And when we have that, maybe it's possible to be more strict about merging PRs.. I will try.
Last edit: Daniel Marjamäki 2021-08-24
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
HEAD has the following exception on our codebase. Note I have to edit the path to prevent spambot from rejecting my post.
~~~ "Cppcheck addons misra.py", line 2077, in misra_10_1
e1_et = getEssentialType(token.astOperand1).split(' ')[-1]
AttributeError: 'NoneType' object has no attribute 'split'
~~~
Unhandled NoneTypes seem to be a very common exception. It has occurred on every one of my upgrade attempts. Seems to me that handling this case needs improvement. At minimum it should produce more information on what the tokens are so I can track down where this happening.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think that cppcheck is getting slower and I also feel currently that it is getting too slow.
However a debug build that does not use the match compiler will be many times slower than a real release build with match compiler.
We have a selfcheck in our CI. We run cppcheck on the cppcheck source code. That step takes 7m45s currently. I would assume it runs a release build with match compiler.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
on my old windows laptop (~8 years old). when I build cppcheck with the above cmake+nmake commands the analysis finish in ~55 seconds. switching to linux then it takes ~6 seconds (make CXXFLAGS=-O2 MATCHCOMPILER=yes). Same computer. Not sure if Windows is really THAT much slower.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I dont think the matchcompiler is the culprit here. The Match function only takes about 5% of the time. Enabling the match compiler on a debug builds only show a slight improvement:
Match off:
real 1m2.216s
user 1m2.175s
sys 0m0.016s
Match on:
real 0m59.209s
user 0m59.173s
sys 0m0.012s
Running the perf report with the Match compiler show these are the top functions:
One thing we could do is check each token if its being changed, by function call, or inconclusive, and then store it in the token class. We can store two bits, one for indirect=0 and another indirect=1. And then pack each bit pairs into a single integer.
This way we can see if its modified faster during analysis. It also would enable the addons to easily check if a variable or expression is modified.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Has anyone tried making a flame graph https://www.brendangregg.com/flamegraphs.html
In some of my performance critical code at work I put them in our CI system. They are pretty easy to look at. Also there is a diff script for them so I have it diff the flamegraph with the last tagged release.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I believe it would be good to more or less have feature freeze from now on. So we can release cppcheck-2.6 later.
If you see "low hanging fruit" tasks; tasks that are small, simple, riskfree and high ROI, feel free to work on that.
I think it would be good to merge PR 3410, as this will fix some FPs.
Last time. there was a release candidate for 2.5. Unfortunately, a number of regressions slipped in after the RC was announced. Maybe this can be avoided this time around.
yes I'd hope we can create a RC in ~ 2-4 weeks when most of the crashes have been fixed. And when we have that, maybe it's possible to be more strict about merging PRs.. I will try.
Last edit: Daniel Marjamäki 2021-08-24
HEAD has the following exception on our codebase. Note I have to edit the path to prevent spambot from rejecting my post.
~~~ "Cppcheck addons misra.py", line 2077, in misra_10_1
e1_et = getEssentialType(token.astOperand1).split(' ')[-1]
AttributeError: 'NoneType' object has no attribute 'split'
~~~
Unhandled NoneTypes seem to be a very common exception. It has occurred on every one of my upgrade attempts. Seems to me that handling this case needs improvement. At minimum it should produce more information on what the tokens are so I can track down where this happening.
Thanks! This bug should be fixed.
To clarify; I fixed it with https://github.com/danmar/cppcheck/commit/43fa7d2ebe05595cfc045eaaea5e15bdc9347678 please continue your testing.
I can confirm it is fixed. Thank you.
With all the new rules come a lot of new messages that I need to look into. I'll follow up with a dedicated thread if I find anything else.
Static analyzer by Microsoft wrote false positive about simple.cpp or cppcheck can't detect problems ?
target : cppcheck-main\externals\simplecpp\simplecpp.cpp
cppcheck output:
microsoft check output:
Also I found infinite loop with cppcheck:
I wait more than 5 minutes for file analyzing....And NOTHING!
I think that cppcheck is getting slower and I also feel currently that it is getting too slow.
However a debug build that does not use the match compiler will be many times slower than a real release build with match compiler.
We have a selfcheck in our CI. We run cppcheck on the cppcheck source code. That step takes 7m45s currently. I would assume it runs a release build with match compiler.
but this is one file, not all cppcheck project.
yes.
with a proper release build:
with a normal debug build:
And I run in Linux. I believe Windows is slower.
I test with DEBUGx64 build, and this woks bigger than 5 minutes (I close after 5 min) at PC with ryzen7 win10
I think it's not very interesting to discuss performance of a debug build without matchcompiler. that is definitely slow.
Do you volounteer to test if the release binary is that slow also?
you can download a nightly build from here:
https://github.com/danmar/cppcheck/actions/workflows/release-windows.yml
The "deploy" artifact contains the files. I believe you can just extract that somewhere on your computer and run.
The "installer" artifact contains an msi installer.
my computer is no real high end computer it's ~3 years old by now.
Can you test this in a visual studio command prompt..
on my old windows laptop (~8 years old). when I build cppcheck with the above cmake+nmake commands the analysis finish in ~55 seconds. switching to linux then it takes ~6 seconds (
make CXXFLAGS=-O2 MATCHCOMPILER=yes
). Same computer. Not sure if Windows is really THAT much slower.I tried run it from artifact and it works without problem.
Strange but now builded DEBUG x64 also works without problem.
I dont think the matchcompiler is the culprit here. The Match function only takes about 5% of the time. Enabling the match compiler on a debug builds only show a slight improvement:
Running the perf report with the Match compiler show these are the top functions:
Running with
-O2
shows these functions:We should try to look at improving the performance of
isVariableChangedByFunctionCall
orgetTokenArgumentFunction
functions.Also, the
-O2
showsfindExpression
, which this could be reduced by caching the expression token inremoveModifiedVars
.One thing we could do is check each token if its being changed, by function call, or inconclusive, and then store it in the token class. We can store two bits, one for indirect=0 and another indirect=1. And then pack each bit pairs into a single integer.
This way we can see if its modified faster during analysis. It also would enable the addons to easily check if a variable or expression is modified.
That sounds good to me.
Has anyone tried making a flame graph https://www.brendangregg.com/flamegraphs.html
In some of my performance critical code at work I put them in our CI system. They are pretty easy to look at. Also there is a diff script for them so I have it diff the flamegraph with the last tagged release.
sounds interesting. I had not even heard about flame graphs before.
This is a flame graph of cppcheck head builded unoptimized with match compiler on. I ran it on cppcheck/lib/ with check=all