Code::Blocks slow as molasses

[Jorg]

Hi,

I am using Code::Blocks to full satisfaction, but sometimes it gets so very slow! The cursor responds per second and the drawing is awefully slow. I am not doing much strange just typing away in the IDE. This can only be resolved when I close C::B and restart. This is however very annoying to do that once every hour or so. Is there a reason why it becomes slow? There is no huge CPU activity, there is nothing going on on my system actually. All other programs respond normally so I think it is an issue with C::B's internal code gathering or threading. What happens when the code is not yet complete and it tries to preprocess it? Is there anything in there that could make it slow?

With regards,
- Jorgen

[rickg22]

Jorg:

a) Whenever it gets slow, press CTRL-ALT-DEL to open the task manager, and check out the memory or CPU usage.
b) Try disabling the code completion plugin and see if things improve.

[Jorg]

Ctrl-Alt-Del does not work. I am in Linux  . And as I said, top (which I use to list processes) does not list C::B as very busy CPU wise. So something is very slow. And I suspect one of the plugins indeed. I disabled them all, and see if that leaves me with a faster version, however it is ofcourse a pity the code completion would cause this. Maybe it is a trigger with uncompleted code, or something it does not understand. Maybe too many open files? I have not a clue unfortunately.

Platform info is:
[Suse 10, Gnome (Metacity Window Manager)]

With regards,
- Jorgen

[Jorg]

Ok this is probably a bug in Scintilla or whatever. Whole Code::Blocks froze up and the CPU load went to 100%. I only have the debugger and the compiler added as plugins but it happened when I selected large blocks of text.

After this the editor stayed again slow as molasses. Very annoying. I think I will edit with Kate, and use C::B for compiling only for the mean time. I nearly lost my code again after a 5 minutes freeze (which it luckily recovered from).

Do you want me to file a bug for it? It is pretty vague as it stands, but I have had these freezes very consequently now.

With regards,
- Jorgen

[rickg22]

OK um... now try disabling the debugger plugin. (Can't get any slimmer than that), and submit a bug report explaining everything. (IMHO this seems like a wxGTK bug).

[takeshimiya]

Ok, to know if it's a Scintilla bug or a Code::Blocks one, can you try using wyoEditor?
http://wxguide.sourceforge.net/editor.html

It's a text editor (like Kate), written in wxGTK and wxScintilla. You can't get closer than that

[Pokemonster]

I have exactly the same problem, running C::B under Linux. The slowdown happens when editing big documents most of the time which is really anoying.
I tried wyoEditor and it works fine so this seems more like a general C::B problem. Disabling all the plugins didn't fix the problem either.

[takeshimiya]

Mm.. I'm noticing some strange slowdown lately also (on windows), but most of times was the codecompletion plugin.

So it seems this will need further investigation.

[Jorg]

I'm glad it isn't just me. Try to look in the area of copy / pasting and selections. That is where I noticed... I am now investigating issues under KDE, but I could not see it get slower there (yet).

Also try to "accidentally" drag the selection that is when I noticed some slowless .. might be a hint I don't know..

- Jorgen

[rickg22]

I think I have a clue... after everything's slow, try selecting ONE character and copying it into the clipoard. Does the problem "go away"?

There's some code, I think, on the OnUpdateUI event handlers, that checked the status of the clipboard. Unfortunately this happens on *every* updateUI. I had added a safeguard for this function to prevent crashes on Linux, but it may still be bugging us. The suspect is in main.cpp, lines 2269 and following.

Code

    if(ed)
    {
        eolMode = ed->GetControl()->GetEOLMode();
        canUndo = ed->GetControl()->CanUndo();
        canRedo = ed->GetControl()->CanRedo();
        hasSel = (ed->GetControl()->GetSelectionStart() != ed->GetControl()->GetSelectionEnd());
#ifdef __WXGTK__
        canPaste = true;
#else
        canPaste = ed->GetControl()->CanPaste();
#endif
    }

    mbar->Enable(idEditUndo, ed && canUndo);
    mbar->Enable(idEditRedo, ed && canRedo);
    mbar->Enable(idEditCut, ed && hasSel);
    mbar->Enable(idEditCopy, ed && hasSel);
    mbar->Enable(idEditPaste, ed && canPaste);

But if it's not that, frankly I don't know.

[Jorg]

I hope it is. I do know it does not have anything to do with larger files my source file was rather small. But everytime I was selecting something, it happened. So your theory could be right .. I will test it later, if it could be the case, I cannot wait to try to compile C::B under linux, however my attempts failed so I will have to try when I have the time again.

- Jorgen

[Clojster]

I'm having the same problem. But even worse... my C::B is slow all the time. wyoEditor has some bug in it. But I don't know if someone will correct it? I can't work like this... I can't even see my cursor while I'm moving it... 

[Michael]

I'm having the same problem. But even worse... my C::B is slow all the time. wyoEditor has some bug in it. But I don't know if someone will correct it? I can't work like this... I can't even see my cursor while I'm moving it... 

Hello,

Which version of C::B/OS do you have?

I work without problems with the latest SVN build.

Best wishes,
Michael

[Clojster]

The problem I described above occurs in RC2. Yesterday I upgraded to SVN build 2211, but the problem is still there. Now I can see the mouse pointer while moving in editor, but typing is terribly slow (cpu usage raise drastically)...

I'm on Linux - Debian Sid, nVidia GF6600GT, latest nVidia drivers from Debian repository, Xorg 6.9 by the way. On Windows everything is fine (I have tried it in vmware). I have the same problem in wyoEditor too.

[Michael]

The problem I described above occurs in RC2. Yesterday I upgraded to SVN build 2211, but the problem is still there. Now I can see the mouse pointer while moving in editor, but typing is terribly slow...

I'm on Linux by the way. On Windows everything is fine (I have tried it in vmware). I have the same problem in wyoEditor too.

I work/test C::B in Linux and it seems not slower than in Windows. Na ja, a bit already, but this is due to my system configuration. A Pentium III 500MHz with 500MB is slower than a Pentium M 1.8GHz with 1GB RAM  . Anyway, I do not have the codestat plugin activated.

Try to de-activate some plugins or all and see if it works better. In your system work all other applications normally (fast)?

Best wishes,
Michael