Activity for Jens Yllman
-
Jens Yllman posted a comment on discussion Development
cppreference state, "std::move is used to indicate that an object t may be "moved from", i.e. allowing the efficient transfer of resources from t to another object. In particular, std::move produces an xvalue expression that identifies its argument t. It is exactly equivalent to a static_cast to an rvalue reference type. " Which kind of say it is never a move, only a conversion of type, which may result in a move. But in this case it will only be a reference to the value. Or am I wrong? Looking at...
-
Hmmm, I wonder how well cppcheck handles other special values in IEEE854.
-
For me the size check is not the most important here. Taking a pointer to a pointer is somewhat suspicious to me. And also the cast, especially since it is a cast from ptr* to ptr. But of curse the size also makes it more suspicious.
-
Yes and no. I could see things you would like to remove/reduce. But the real reason for the really slow execution was that instead of having more or less 'flat' flow with only one level of recursion there was overflow which caused where much recursion and very slow.
-
No, it did not. And now when I found the real problem the flamegraph is really boring.
-
So, the use of isKeyword() might be good. But with the 'fix' I put in as a PR #4235 this optimization might not be so needed. The fix instead tries to stop overstepping endToken in the loop in forwardRange().
-
To me now, it looks like even if you have an endToken into forwardRange() it continues past that end token cause some actions will end on the endToken, and then there is a ++ end then a check if endToken. But then we are past already.
-
Actually, it seem that the thing that triggered the scan to the end of the file is that in the example file in #10933 the if conditions are actually assignments not compare. So I am now looking on the code in forwardRange() that looks at the condition. If you change the ifs to == instead of = it finishes in no time.
-
Why do we want forwardRange() to go to the end of the file and not to the end of the scope?? In the case of #10933, the example file does add 'many' rows to the info.errorPath, which makes the 'copy' into a new call to forwardRange() very costly. If I reduce the number of rows in info.errorPath, the time is very much reduced.
-
Is it not so that CMAKE_C_CPPCHECK is a variable set by find_program() trying to see if cppcheck is available. And it might not even be in 'upstream' CMake yet. And CMAKE_C_CPPCHECK is supposed to contain the command line to run cppcheck. So it depends on the implementation to find cppcheck what it puts into CMAKE_C_CPPCHECK. So if you can get the content of CMAKE_C_CPPCHECK you will see how cppcheck is run.
-
Is it not so that CMAKE_C_CPPCHECK is a variable set by find_package() trying to see if cppcheck is available. And it might not even be in 'upstream' CMake yet. And CMAKE_C_CPPCHECK is supposed to contain the command line to run cppcheck. So it depends on the implementation to find cppcheck what it puts into CMAKE_C_CPPCHECK. So if you can get the content of CMAKE_C_CPPCHECK you will see how cppcheck is run.
-
So some more info. When you look at the flame graph it might be the fact that memory allocation takes up to much of the time in forwardRange()/forewardRecursive(). And since the 'algorithm' is recursive, it adds up to memory allocation takes a lot of the time in the #10933 example.
-
Yes, that might be one way to go. I 'fear' that the way I put in the isKeyword() check now, works and 'looks' OK when you do not think about match compiler. So if the match compiler knows about it, the resulting code might get more 'correct'.
-
So I now also did a run where I had the same settings as John Borland had in his run on another thread. And using perf instead of -pg to generate a FlameGraph. It's all forwardRange(). The graph I attach to this thread is run with the isKeyword(), but removing that will give the same graph. I might do a higher sample frequency to see if something else will show.
-
Yes, it is true multiCompare() only show up if you do not use the match compiler. But even with the match compiler adding the isKeyword() gives little performance boost. Running the file in #10933 with isKeyword() takes 41m23s and without it takes 42m41s, both with match compiler and -O2 -DNDEBUG. But it is small, and I think it does not help understanding the reason for the code. -g and no match compiler and no isKeyword() takes 276m23s. Same compile but -pg instead of -g to run the profile takes...
-
Just a small comment. Some things might light very big in profiling. But, running profiling removes the benefit of optimization. But at least it shows the number of calls. That can be important.
-
So, now when keeping the multiCompare() 'low' in the profiling the top 20 is things are related to std::string and something that looks like std::list. So, are we copying strings to much? Triggered by copying the token list? But the profile output I have does not show where the calls are coming from. 13495308729 calls to std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_data() const is what seem to use the most time. with 1432802144 calls to void std::__cxx11::basic_string<char,...
-
OK, so doing this did speed up all my tests. Even running the example in #10933. It still took way to long but. But now I am trying to run profiling on that example. And I am soon at 24h waiting. But since I now know it can finish I will wait and look at the result. The example above about 2805817 calls to multiCompare() now only does 90000+ calls. And the existing test still report OK.
-
Currently there seem to be multiple complaints about cppcheck being slow. And in the two cases I have looked at it is because Token::multiCompare() gets called very many times from PathAnalysis::forwardRange(). For instance, the first thing that happens in the loop of forwaredRange() is if (Token::Match(tok, "asm|goto|break|continue")) This will trigger multiCompare(). would it not be smart to first do tok->isKeyword()? I will do some testing and see if this might be something to do. Just some numbers....
-
Do you have python3 installed?? It used to be running python before. But that fails on system that does not default to python3.
-
So if you look at the example in #10933 it is the size of the file that make it take very long time. If you cut it down it will go quicker. If you profile the run you till see that Token::multiCompare() will take up most of the time. And like PathAnalysis::forwardRange the rest of the time. And multiCompare() is maybe a result of all the calls to Token::Match() in forwareRange(). I have no real solution at the moment. Maybe limiting the tokens called with multiCompare(), cause it looks like it is...
-
#10933 is also about invalidContainer and PathAnalysis. In the test I have not come to any crash. But it takes very long time. I have not run it long enough to finish or crash. And running it in the debugger just show it SLOWLY going forward. I am running my tests on cppcheck 2.7.
-
#10933 is also about invalidContainer and PathAnalysis. In the test I have not come to any crash. But it takes very long time. I have not run it long enough to finish or crash. And running it in the debugger just show it SLOWLY going forward.
-
The thing is that cppcheck does not know that __has_include() is not a normal function. So it does not manage to identify the argument, since it it not a valid argument to a normal function.
-
Or an option to not start gpg-agent as a daemon?
-
Or actually. It would be kind of nice to have cygwin support built in. I wonder how much work it would be to skip the checks if we in cygwin? :)
-
I think there is a need for a guide how to do with cygwin and gpg4win together!
-
Does Enigmail start the gpg-agent as daemon?? Is there some way till stop that daemon nice?? Cause that process is creating a lock when signing/encrypting. And it would be nice if thoose locks got released when you close Thunderbird. Also, there are some other locks that does not get released when you modify your keystores. It is easy to delete. But I would like them to go away nice. Why keep the locks after operation finished??
-
OK, I did let Enigmail install Gpg4Win. And that install actually could see that I allready had a gpg install and a home directory in cygwin. So it set homedir to that directory. And now everything seem to work. But, having Thunderbird open keeps lockfiles that make gpg from cygwin fail. I will look some more into that. I do not use gpg that often in cygwin, yet.
-
OK, I did let Enigmail install Gpg4Win. And that install actually could see that I allready had a gpg install and a home directory in cygwin. So it set homedir to that directory. And now everything seem to work.
-
So, setting the registry key does not help. Now I am back to how it was first.
-
OK, I will try, but this is cygwin version of GPG, so I do not think it reads the regestry. And nothing is in the regestry now. Using --homedir "C:\path\to\gpghome" makes Enigmail happy. But I understand that GPG is not happy. Since it wants /home/user/.gnugp. So the question is why do Enigmail need to physically check the home directory. If all was left to GPG in this case I just think it works. It did work before 2.0 with same install of cygwin and gpg.
-
The thing is that if I do not specify homedir I get the cygwin setting which is /home/user/.gnupg. And when I specify homedir enigmail will say config found. But that the config is missing the GPG_AGENT_INFO. So the question is, how did enigmail 1.9 do this that 2.0 does not? And can we work around it in 2.0? Cause the cygwin environment is the same.
-
After setting the homedir I now get gpgAgent.jsm: setAgentPath: gpgconf found: yes but directly after that I get gpgAgent.jsm: detectGpgAgent: no GPG_AGENT_INFO variable set gpgAgent.jsm: detectGpgAgent: GPG_AGENT_INFO='none' Could that be the reason why the keyring operations does not work??
-
That got me past the initialization error. I did --homedir "C:\...." and it worked. But now I get key errors instead when I try to sign/encrypt.
-
Also, another note, you never can add this parameter during wizard setup. So doing it that way will never work. And you have to set the extra parameter before you select the gpg2.exe file in cygwin, or it will not work eather.
-
That got me past the initialization error. I did --homedir "C:...." and it worked. But now I get key errors instead when I try to sign/encrypt.
-
I have tried to follow the flow of initialization of enigmail. And it looks like it fails when it is checking home directory for gpg. That is where the .gnupg file is. That is in cygwin format not in windows format. But I can not say for sure. Does enigmail really need to know where this file is?? Running the cygwin gpg version of gpg will read the correct file anyway. Note: old version that is working can not run in TB60. so need a new working enigmail.
-
I have tried to follow the flow of initialization of enigmail. And it looks like it fails when it is checking home directory for gpg. That is where the .gnupg file is. That is in cygwin format not in windows format. But I can not say for sure. Does enigmail really need to know where this file is?? Running the cygwin gpg version of gpg will read the correct file anyway.
-
When you choose the file it say it is not a gpg exec. But I have seen, since I have this setting since before that it runs the tool. So setup fails to like the file. And later you can not use it for signing or encrypting.
-
Cygwin version of gpg does not work in 2.x
1
