added Token::exactMatch()

[firewave]

This introduces Token::exactMatch() to use when the pattern to match is just a single one replacing calls like Token::simpleMatch(tok, "this").

Using GCC 11 it is unfortunately a bit slower going up from 867,907,022 to 868,475,717 in a matchcompiled -O2 build.

Using Clang 13 this even makes it faster going down from 771,620,532 to 771,005,754 in a matchcompiled -O2 build. In a non-matchcompiled -O2 build it went down from 1,444,102,556 to 1,380,104,125.

These numbers were collected using cli/threadexecutor.cpp. Some bigger testrun needs to be done.

I will look into the GCC regression as well as big speed difference between the compilers. It is a bit weird though since the code is the same as the matchcompiled version would be using and even without the ConstString indirection.

[firewave]

The added TODOs in checkinternal.cpp causes issues with matchcompiler.py.

The assert calls are just temporary before the internal checks can handle all the changes.

I will need some help with getting the internal checks added for the following: Token::simpleMatch(tok, "this") -> replace with Token::exactMatch() Token::exactMatch("this that") -> replace with Token::simpleMatch()

Some other patterns which might be interesting: tok && tok->str() == "this" -> replace with Token::exactMatch() !tok || tok->str() != "this" -> replace with !Token::exactMatch()

tok->str() == "this" -> replace with Token::exactMatch() (would this cause a regression because of the additional pointer checks?) tok->str() != "this" -> replace with !Token::exactMatch() (would this cause a regression because of the additional pointer checks?)

[danmar]

hmm.. I am not sure I like to have different methods to start with. Before the match compiler it definitely made sense. I usually run without matchcompiler when I test cppcheck on various projects but I often don't find the execution time that disturbing.. if the execution time would be too long then why not use match compiler?

Using Clang this even makes it faster

I don't know why exactMatch is faster than the generated Match output. If we can speed up the code generated by match compiler that would be good.

[firewave]

hmm.. I am not sure I like to have different methods to start with. Before the match compiler it definitely made sense. I usually run without matchcompiler when I test cppcheck on various projects but I often don't find the execution time that disturbing.. if the execution time would be too long then why not use match compiler?

This gets rid of the need to matchcompile this code and uses the same behavior across all kinds of builds. The dependency to the matchcompiler.h will be removed by some refactoring. The impact is quite minimal with the same results. If this is backed by internal checks all the new code will be clean as well.

I think the added function can also be used by the matchcompiled code and simplifying it and possibly even getting rid of the additional match function in some cases. That might also help a bit with compilation time.

The main reason we need the matchcompiled code are the Token::Match()/multicompare calls. I have small refactoring which will speed up the non-matched compiled code as well as a minor improvement for the matchcompiled code.

There's also some cleanups which can be done in token.h which will make the interface a bit cleaner.

I really hate that we have to matchcompile the code or jump through other hoops (looking at you std::stack) to get proper speed so I would like to get rid of it as much as possible since you should be able to write performant code which doing such crazy things. As we can see it's highly dependent on the compiler (which is quite surprising since we don't do anything special in our code) and I will try to get tickets filed upstream so this improves in the future. Or with us if it is related to some coding pattern.

And there's also LTO and -O3 to look at.

[firewave]

See also #4337 and https://trac.cppcheck.net/ticket/11252.