Code completion is unusably slow

[xhpohanka]

Hello,
I'try to use CB for development, but in latest versions the code completion seems to be unusable. I have downloaded latest nightly build and than tried to edit some projects. If the project is small (for ex. embedded design) everything is ok, but with larger projects (codeblocks source, wx form project, ...) every typing is extremely slow. I write 5 characters and they show up in 2 seconds. After disabling the cc plugin cb works fine.
I have found many issues related to code completion, but not relating this slow behaviour. Is there any solution? I remember that older versions worked better.

greetings Jan

[Kriz]

Unfortunately I must confirm this, too! The current Code Completion plugin (v0.7) slows down typing extremely and I don't know why. If I press a key and keep it pressed the editor stops displaying the line until I release the key again. In my opinion the completion plugin is simply overextended with medium to large projects.

Disabeling the plugin sweeps all problems away including the fact that I have no code completion any more. Beside that I realized that the completion plugin can be accelerated when disabeling the "GLOBAL Includes" parser option. This works fine for the "standard" thing, but drives me crazy when coding with large libraries in the background (like QT4).

I hope somebody will review the plugin soon...

[ollydbg]

there is a cc_branch and have many bug fix and feature added. can you tried that?
if not, you can post the source code, then I can check it.

[ollydbg]

with larger projects (codeblocks source, wx form project, ...) every typing is extremely slow. I write 5 characters and they show up in 2 seconds. After disabling the cc plugin cb works fine.

I can't reproduce this bug when editing codeblocks source or wx project.
I'm using codecompletion_refactor_branch.
If you still has this problem, let me known.

[Kriz]

Hm...

I have found out that the plugin has problems while differing between two classes with the same class name but different namespaces. For example in my QT4 projects (I'm using the QT Designer tool for RAD) the designer tool produces code embedded into a namespace called Ui. Lets say the name of this embedded class is MainWindow, so its fully qualified name is Ui::MainWindow.

Naming my derived class with the same name MainWindow causes trouble with the plugin:

Code

#include <qmainwindow>
#include "ui_mainwindow.h" // Produced by the designer tool

class MainWindow 
: public QMainWindow, 
  public Ui::MainWindow
{
    ...
};

Now the plugin cannot differ between Ui::MainWindow and MainWindow accessings! Sure, I could rename my derived class and everything works fine, but in my opinion this behaviour is not very satisfying, isn't it?

[ollydbg]

Ok, I will look into it. it seems there is a bug in parserthread's DoParse function.

[ollydbg]

@Kriz

I just wrote a simple test code, and every thing works fine.

Code

class QMainWindow
{
    int aaaa;
};

namespace Ui {

    class MainWindow
    {
        int bbbb;
    };

}

class MainWindow
: public QMainWindow,
  public Ui::MainWindow
{
    int cccc;
};

MainWindow x;
x.

Naming my derived class with the same name MainWindow causes trouble with the plugin:

So, What the exact problem you have with CC?
Can you describe it more specifically?

[Kriz]

Hm... very strange. Does the plugin has known problems while parsing a huge amount of code (backparsing all QT headers in one run _is_ a huge amount of code  )? Well, I don't know how to pull the string shorter around this problem, but I do have this "funny" phenomenon. When coding standard C/C++ I cannot recognise any problems. Everything works fine then.

Another mystery: In the prior version of C::B, when I typed std:: the plugin showed me the correct selection of possible classes (f.e. vector or something like that). Now in the new version the plugin shows me the selection of possible (standard) classes without typing std:: before! More better: When I type std:: the possible classes will not appear anymore! WTF?

And last but not least: The popup combobox of the plugin should calculate its position before showing, because often nearly half of the window floats over the bottom border of the editor pane:



I hope this bug will be solved soon 

Cu
Kriz

[ollydbg]

I do not have qt at hand, so I just test a simple vector code like:

Code

#include <vector>

//using namespace std:

std::ve

then the screen shot shows it works fine.(latest cc_branch)



note, I reopen(reparse) the project after I edit the code.( this means the #include <vector> should be there if you open the project, seems parsing in realtime does not add new headers to parser..).

[xhpohanka]

Hello,
I've tried again the latest nightly build (6527) on Windows 7. Unfortunately code completion still works strange on all my computers.

Steps performed:
1. Clean install of latest CB
2. Open the CB source project (wx included)
3. Open any file
4. Writing of any text

Symptoms:
After writing 4th character (corresponds to CC configuration), the writing starts to be very slow.

Am I the only one with similar behaviour?

regards Jan

[ollydbg]

could you try to build  cc branch yourself, and test it again

[xhpohanka]

could you try to build  cc branch yourself, and test it again

I hope cc branch means codecompletion_refractoring ...
It seems to work slightly faster, but still annoying.
When I type 4 characters and cc don't know the word, I assume it should stop searching possible matches, but it is still slow...

[blueshake]

did you do this??