Repository navigation
Conversation
|
There should probably be a trac ticket for this PR. Please create it, or ask us to create it. Then the PR title should be updated. |
Author
|
Ah, could you create one for me? Or is there a way for me to create them?
There is another pretty sizeable performance improvement I'm working on.
This time in reducing tokens being read many times over. But that'll take a
bit longer.
Once there's a trac ticket for this PR I'll update it.
Met vriendelijke groet,
Michael de Lang
…On Sun, 25 Oct 2026, 23:01 Daniel Marjamäki, ***@***.***> wrote:
*dmcppcheck* left a comment (cppcheck-opensource/cppcheck#8960)
<#8960 (comment)>
There should probably be a trac ticket for this PR. Please create it, or
ask us to create it. Then the PR title should be updated.
—
Reply to this email directly, view it on GitHub
<#8960?email_source=notifications&email_token=AABTZJUAS735N5GIHE3FZNT5VZSZDA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTMNBQGM4TGMBSG44KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-6403930278>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABTZJSXDJFO5UDAHPCS4I35VZSZDAVCNFSNUABCKJSXA33TNF2G64TZHMYTIMZRGMYTWSLTON2WKOZWGAZDQOJWG4ZTKMVBOYBA>
.
Triage notifications, keep track of coding agent tasks and review pull
requests on the go with GitHub Mobile for iOS
<https://github.com/notifications/mobile/ios/AABTZJQCX4PEISRAI26HAK35VZSZDA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTMNBQGM4TGMBSG44KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG>
and Android
<https://github.com/notifications/mobile/android/AABTZJUMDCZCCATDQN2OEKT5VZSZDA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTMNBQGM4TGMBSG44KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>.
Download it today!
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Collaborator
|
I have created this ticket: |
Oipo
changed the title
Author
|
Thanks. Updated the PR title and the two commits. |
danmar
reviewed
Oct 26, 2026
| deletionsCollected = true; | ||
|
|
||
| for (const Variable* var : mSymbolDatabase->variableList()) { | ||
| if (var && var->isPointer() && var->type()) |
Collaborator
There was a problem hiding this comment.
I would suggest a && var->nameToken() also. unnamed parameters will not be added then.
Author
There was a problem hiding this comment.
Yeah, that is more readable. Added.
| { | ||
| // pointer variables of type 'Base *' | ||
| std::set<int> baseClassPointers; | ||
| collectDeletions(); |
Collaborator
There was a problem hiding this comment.
it does not look right to me to call this in the loop. It will go through all variables in symboldatabase and add declaration ids to pointersByType over and over again? can't we just do that once?
Author
There was a problem hiding this comment.
I initially thought making it lazy would save time on TU that don't have any public base classes, but I measure <0.05 ms difference so noise basically. I removed the lazy part.
https://trac.cppcheck.net/ticket/15143 CheckClassImpl::virtualDestructor() scanned the whole variable list and the whole token list for every (derived class, public base class) pair. With many template instantiations (for example etl) this took up to 26% of the analysis time. The named pointer variables of each type are now collected once, and a single pass over the tokens records, for each pointer variable, the classes 'Derived' of a "ptr = new Derived" that is followed by a "delete ptr;". Checking a pair is then a lookup. This also fixes a false negative: the name of a template instantiation such as 'Derived < int >' is a single token that contains spaces, so the old pattern "new Derived < int >" never matched it and the pair was never reported. On a project using etl, glaze and Catch2 (211 translation units in two configurations) total CPU time drops from 88.7 to 61.6 minutes, with identical output for every translation unit.
https://trac.cppcheck.net/ticket/15143 Tokenizer::setVarIdPass2() tried every out-of-class member definition for every class. matchMemberName() can only succeed when the innermost scope name of the class matches a name in the member's scope, in one of its "using namespace" or in its qualification. The members are now indexed by those names, in their original order, so each class only tries its candidates. The index and matchMemberName() walk the qualification with the same skipQualification(). On the same project total CPU time drops further from 61.6 to 52.9 minutes, with identical output for every translation unit.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two improvements:
On my own private project, the total CPU time dropped from 88.7 minutes down to 52.9 minutes. Oh, and this also fixes a false negative:
new Derived < int >would never match, and it does now. See some tests I added.