I've had a look through the issues, and can't see anything recent that pertains; I've currently got 1.80 rolled out and was running 1.83 to see what the changes were. Normally cppcheck doesn't take terribly long across our codebase, but I started 1.83 yesterday afternoon and it was still only halfway done this morning!
A verbose/progress run show the following sort of output:
Is the code publicly available so we can reproduce it locally?
Cppcheck 1.84 has added a lot more checks and analysis than in previous version. There is more places we are checking for same expressions and opposite conditions. We also have checks for duplicate assignments.
It could also be related to one of these tickets, which are changes made recently to the TemplateSimplifier:
No, unfortunately it's proprietary, but it's visible at the get go (and as I said, in 1.83, so 1.84 changes aren't likely to be relevant) so it should be possible to create a cut down example.
It won't be a trivial task, which is why I was hoping someone might have an idea off the bat!
I'll see about building 1.81 & 1.82 as well so as to ID which release triggered the problem.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm not sure what you were expecting out of the older versions, but it's not much! Does look like it was something that went in between 1.82 and 1.83. These are the results over one small file (that admitedly includes quite a few of our headers):
I don't hold out much hope producing a cut-down example, the slow down appears to be, if not linear, then a scale factor of the volume of code. The (awaiting moderation) timings are from a file in our third library to build, which will be including the library headers of the fist two libraries (plus a couple of local ones).
Hiding library 2's headers (~3000 SLOC) drops the run time from 107s to 93s; hiding the first (~18,000 SLOC) as well takes it to 8s.
Vs., of course, e.g., 1.82's 0.01s.
Oh. OK. <checks using="" strace="">
Damn, that complicates matters. Prior to 1.83, those headers weren't being included. This is likely down to an old bug that mishandled macros in #include statements (which we use). I suspect, then, that that was fixed in 1.83 (hmm, that may even be why I was awaiting that version ...) and now we're seeing all headers being processed (for all files).
So the slow down from my perspective has potentially been there for quite some time, but hidden by files only being able to see their local headers.
Not sure where I can go from here; I think I'll just have to remove the -I option to mimic the old process and suffer the loss of the better diagnostics that would give me.
Maybe I'll trigger a weekly job to run the whole lot; I don' t know yet how long that will take to finish!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've had a look through the issues, and can't see anything recent that pertains; I've currently got 1.80 rolled out and was running 1.83 to see what the changes were. Normally cppcheck doesn't take terribly long across our codebase, but I started 1.83 yesterday afternoon and it was still only halfway done this morning!
A verbose/progress run show the following sort of output:
Those template lines come out at a rate of about one every 30 seconds per file, where with 1.80 each file is processed in under a second.
I've just built 1.84 (CentOS 7, FWIW) and it behaves the same way.
Does anyone have any thoughts?
(I can compare 1.81 and 1.82 if need be, but I'd have to download and build them first)
Is the code publicly available so we can reproduce it locally?
Cppcheck 1.84 has added a lot more checks and analysis than in previous version. There is more places we are checking for same expressions and opposite conditions. We also have checks for duplicate assignments.
It could also be related to one of these tickets, which are changes made recently to the TemplateSimplifier:
https://trac.cppcheck.net/ticket/7406
https://trac.cppcheck.net/ticket/8605
https://trac.cppcheck.net/ticket/8314
https://trac.cppcheck.net/ticket/8315
https://trac.cppcheck.net/ticket/7868
https://trac.cppcheck.net/ticket/8175
https://trac.cppcheck.net/ticket/8241
https://trac.cppcheck.net/ticket/8283
No, unfortunately it's proprietary, but it's visible at the get go (and as I said, in 1.83, so 1.84 changes aren't likely to be relevant) so it should be possible to create a cut down example.
It won't be a trivial task, which is why I was hoping someone might have an idea off the bat!
I'll see about building 1.81 & 1.82 as well so as to ID which release triggered the problem.
can you run 1.80 and 1.84 with the option --showtime=summary and then publish the results? It's enough if you run it on a single file.
Last edit: Daniel Marjamäki 2018-07-13
I'm not sure what you were expecting out of the older versions, but it's not much! Does look like it was something that went in between 1.82 and 1.83. These are the results over one small file (that admitedly includes quite a few of our headers):
1.80
1.81
1.82
1.83
1.84
BTW, I see this sort of odd counting a lot:
I don't hold out much hope producing a cut-down example, the slow down appears to be, if not linear, then a scale factor of the volume of code. The (awaiting moderation) timings are from a file in our third library to build, which will be including the library headers of the fist two libraries (plus a couple of local ones).
Hiding library 2's headers (~3000 SLOC) drops the run time from 107s to 93s; hiding the first (~18,000 SLOC) as well takes it to 8s.
Vs., of course, e.g., 1.82's 0.01s.
Oh. OK. <checks using="" strace="">
Damn, that complicates matters. Prior to 1.83, those headers weren't being included. This is likely down to an old bug that mishandled macros in #include statements (which we use). I suspect, then, that that was fixed in 1.83 (hmm, that may even be why I was awaiting that version ...) and now we're seeing all headers being processed (for all files).
So the slow down from my perspective has potentially been there for quite some time, but hidden by files only being able to see their local headers.
Not sure where I can go from here; I think I'll just have to remove the -I option to mimic the old process and suffer the loss of the better diagnostics that would give me.
Maybe I'll trigger a weekly job to run the whole lot; I don' t know yet how long that will take to finish!