CodeCompletion slow on some machine

[ollydbg]

CB is not compiled with the compiler option -pg, correct ? I will need to recompile it.

Yes, recompile is need. (I have once recompiled CC plugin with -pg to profile it).

it would be better to provide 2 patches : one for the additionnal profiling, and one for the code change.

Some times, I have also meet this kind of issue, I have two different changes on the same file. No idea how to  create two consequence patches. Maybe, Git can help me. 

And please be patient : I can debug this problem only at work, and I have since more than 1 year a very high pressure on my project (reason why other projects seem abandonned, like the xpmeditor). I cannot afford to spend too much time in a row on this problem. I hope everybody can understand that.

I think any kind of contribution is valuable. Thank you!!!

[MortenMacFly]

Some times, I have also meet this kind of issue, I have two different changes on the same file. No idea how to  create two consequence patches. Maybe, Git can help me. 

No, GIT won't help.

That's why I have a actually 2 working copies, one is SVN-controlled:
When I want to merge something into trunk I first use a diff tool to pump it from my working- into into the SVN-working copy and then create a patch, revert the changes in the svn-working copy and apply the nest modifications etc...

[jarod42]

Some DVCS support shelving (which may be done by chunk).
and 'git add --patch' seems to solve your issue.

[oBFusCATed]

ollydbg:
gprof is useless when you have shared libraries. It only works well for statically linked applications or at least I've not been able to make it work.
You need something like Intel V-Tune or oprofile.

[MortenMacFly]

gprof is useless when you have shared libraries. It only works well for statically linked applications [...]

That's why I wrote:

I guess using the profiler plugin and a testing environment you can do much better ;-)

By that I meant out test ParserTest project, if that is sufficient for that purpose - depending on where the lag would be, it may not cover all methods affected.

[seb_seb0]

I have made a few progress:
  1 - -pg does not help : the gmon.out is empty. I have seen somewhere on the net how to enable gprof for multithreaded applications. Perhaps it would help
       For now, the good old printf method is sometimes unbeatable (simple and effective).

  2 - when amount of parser threads is set to 1 per project, the freeze does occur
       when the amount of parser threads is set to 2 or more per project, there are no more freeze.
       Using 1 parser for the whole workspace does not provoke the freeze. However, on the work computer (Win XP), the CodeCompletion does not give results. It works however on Win7

  3 - I have tried to launch Code::Blocks in the debugger gdb, and paused the process during the freeze: I end up each time in a ntdll!DbgUiConnectToDbg. So not a lot of help here for now. (and yes, I was using Code::Blocks with debug symbols enabled).

So in short : I have found a workaround for making it work on both machines. This is however not really satisfying, because I still do not understand what happens exactly. So I will continue to search for an explanation (why do we have a freeze with 1 parser and not with 2 ?)

Seb
 

[seb_seb0]

ollydbg:
gprof is useless when you have shared libraries. It only works well for statically linked applications or at least I've not been able to make it work.
You need something like Intel V-Tune or oprofile.

oprofile is Linux only (I work on Windows), and Intel V-Tune costs a bit (for that, I do not think my boss will be very happy to pay for it). If you know another profiler than gprof, I would be happy to hear from it.
I will try CodeTune (just found it, I do not know how to use it yet).

[ollydbg]

I have made a few progress:
  1 - -pg does not help : the gmon.out is empty. I have seen somewhere on the net how to enable gprof for multithreaded applications. Perhaps it would help
       For now, the good old printf method is sometimes unbeatable (simple and effective).

Though gprof is said to be useless, it does generate the gmon.out file in my cases(build CC with -pg enabled, several months ago).

 2 - when amount of parser threads is set to 1 per project, the freeze does occur
       when the amount of parser threads is set to 2 or more per project, there are no more freeze.
       Using 1 parser for the whole workspace does not provoke the freeze. However, on the work computer (Win XP), the CodeCompletion does not give results. It works however on Win7

There are some basic logic about this. If one parser for the whole workspace, which means we have only one instance of the Parser class, and all tokens were added to the one TokensTree. On the other side, if one parser for one c::b project, this means there are many instances of Parser, each Parser object holds the corresponding tokens for each project. This feature is added  by Loaden who is not active for half a year.

 3 - I have tried to launch Code::Blocks in the debugger gdb, and paused the process during the freeze: I end up each time in a ntdll!DbgUiConnectToDbg. So not a lot of help here for now. (and yes, I was using Code::Blocks with debug symbols enabled).

At this case, you can run "step out" or "step", or the "backtrace" to see the call-stack in each thread or set some breakpoints where you believe is a endless loop.

[ollydbg]

Some DVCS support shelving (which may be done by chunk).
and 'git add --patch' seems to solve your issue.

Thanks, I do not familiar with gdb shelving.
But Git can generate a sequence of patches. When I read the GDB patches maillist, I always see some posts like:
[Patch XXX 0/2]
[Patch XXX 1/2]
[Patch XXX 2/2]
Each posts contains one piece patches, but I can see they were generated by Git. You need to apply the patch in sequence.
Note: GDB code repo is controlled by CVS, but many GDB developers were using Git for maintaining patches.

PS: Biplab has constructed a Git read-only repo for C::B.