Fix #15143: Improve performance in the case of many template instantiations by Oipo · Pull Request #8960 · cppcheck-opensource/cppcheck

Oipo · 2026-10-25T20:31:30Z

Two improvements:

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.
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 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.

dmcppcheck · 2026-10-25T22:00:43Z

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.

Oipo · 2026-10-25T22:23:44Z

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: ***@***.***>

danmar · 2026-10-26T07:00:41Z

I have created this ticket:
https://trac.cppcheck.net/ticket/15143

Oipo · 2026-10-26T07:31:03Z

Thanks. Updated the PR title and the two commits.

danmar · 2026-10-26T13:59:34Z

+        deletionsCollected = true;
+
+        for (const Variable* var : mSymbolDatabase->variableList()) {
+            if (var && var->isPointer() && var->type())


I would suggest a && var->nameToken() also. unnamed parameters will not be added then.

Yeah, that is more readable. Added.

danmar · 2026-10-26T14:02:37Z

                {
-                    // pointer variables of type 'Base *'
-                    std::set<int> baseClassPointers;
+                    collectDeletions();


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?

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.

Oipo · 2026-10-28T09:29:50Z

I got an e-mail with a comment you made, but I cannot find it here anymore. If there's any questions you have, let me know and I'll do my best to answer them.

dmcppcheck · 2026-10-29T05:21:23Z

Test results for commit ab38a74 (tools/test-my-pr.py, main compared to this PR):

Test: http://ec2-16-170-140-253.eu-north-1.compute.amazonaws.com/pr-8960/
packages: 1000
Differing warnings: 0 (+0 -0)
Timing: -0.8% (http://ec2-16-170-140-253.eu-north-1.compute.amazonaws.com/pr-8960/2026-10-26_20-05-11-ab38a743b573_timing.html)

_{Posted automatically by the cppcheck PR test runner. +N: warnings only with this PR, -N: warnings only with main. The AI review is written by Claude and can be wrong.}

dmcppcheck

AI review

I found no new problems.

I traced through matchMemberName(): every step that moves scopeIt forward first requires the name to be equal. So a match is only possible when the last name in scopeInfo occurs in member.scope, in a using namespace chain, or in the member's qualification. These are exactly the names that indexMembersByScopeName() indexes, and it walks them with the same skipQualification(). Two more things hold up:

Candidate order is kept.
The Member* pointers stay valid, because the members are in a std::list that the loop does not change.

The new virtualDestructor() gives the same results as the old per-pair scan, except for the intended fix for template-instantiation names (Derived < unsigned int >), which I confirmed works.

Testing

Build: make -j8 cppcheck testrunner succeeded in pr/, and make -j8 cppcheck succeeded in base/.
Test suites: ./testrunner passed with 0 failures for TestClass, TestVarID, TestTokenizer, TestSimplifyTemplate, TestSymbolDatabase, TestConstructors and TestUnusedVar.
Base vs PR on existing code: I ran cppcheck --debug --enable=all --inconclusive from base and from the PR on all test/cfg/*.cpp files (each with its matching --library) and on lib/token.cpp, lib/mathlib.cpp and lib/library.cpp. Debug output and warnings were byte-identical.
Varid edge cases (base vs PR): nested classes, using namespace N, using namespace X::Y, using namespace inside a namespace body, members of template classes (S<T>::h), and constructor initializer lists for out-of-class members. The debug output was identical and the varids were correct.
virtualDestructor edge cases (base vs PR): new NS::D3, new Derived(1) inside a nested block, a local Base *r, and several derived classes. Results were identical.
Template false negative: for p = new Derived<unsigned int>; delete p;, base reports nothing and the PR reports Class 'Base' which is inherited by class 'Derived < unsigned int >', as intended.
Stress test: a generated file with 1500 namespaced derived classes, their out-of-class member definitions and new/delete through Base* took 8.7 s with base and 2.7 s with the PR. Both produced the same output (4500 lines).

Automated review of ab38a74 by Claude. The pull request was built and tested locally.

Oipo force-pushed the main branch from 0fea70d to 27afce0 Compare October 26, 2026 07:30

Oipo changed the title ~~Improve performance in the case of many template instantiations~~ Fix #15143: Improve performance in the case of many template instantiations Oct 26, 2026

danmar reviewed Oct 26, 2026

View reviewed changes

Oipo added 2 commits October 26, 2026 21:05

Oipo force-pushed the main branch from 27afce0 to ab38a74 Compare October 26, 2026 20:05

dmcppcheck reviewed Oct 29, 2026

View reviewed changes

Navigation Menu

Repository navigation

Fix #15143: Improve performance in the case of many template instantiations - #8960

Fix #15143: Improve performance in the case of many template instantiations#8960
Oipo wants to merge 2 commits into
cppcheck-opensource:mainfrom
Oipo:main

Oipo commented Oct 25, 2026

Uh oh!

dmcppcheck commented Oct 25, 2026

Uh oh!

Oipo commented Oct 25, 2026 via email

Uh oh!

danmar commented Oct 26, 2026

Uh oh!

Oipo commented Oct 26, 2026

Uh oh!

danmar Oct 26, 2026

Uh oh!

Oipo Oct 26, 2026

Uh oh!

danmar Oct 26, 2026

Uh oh!

Oipo Oct 26, 2026

Uh oh!

Oipo commented Oct 28, 2026

Uh oh!

dmcppcheck commented Oct 29, 2026

Uh oh!

dmcppcheck left a comment

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

Oipo commented Oct 25, 2026

Uh oh!

dmcppcheck commented Oct 25, 2026

Uh oh!

Oipo commented Oct 25, 2026 via email

Uh oh!

danmar commented Oct 26, 2026

Uh oh!

Oipo commented Oct 26, 2026

Uh oh!

danmar Oct 26, 2026

Choose a reason for hiding this comment

Uh oh!

Oipo Oct 26, 2026

Choose a reason for hiding this comment

Uh oh!

danmar Oct 26, 2026

Choose a reason for hiding this comment

Uh oh!

Oipo Oct 26, 2026

Choose a reason for hiding this comment

Uh oh!

Oipo commented Oct 28, 2026

Uh oh!

dmcppcheck commented Oct 29, 2026

Uh oh!

dmcppcheck left a comment

Choose a reason for hiding this comment

Testing

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants