Author Topic: Code::Blocks slow as molasses  (Read 17453 times)

Offline Jorg

  • Multiple posting newcomer
  • *
  • Posts: 32
Code::Blocks slow as molasses
« on: November 28, 2005, 08:45:21 pm »
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

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: Code::Blocks slow as molasses
« Reply #1 on: November 28, 2005, 08:50:08 pm »
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.

Offline Jorg

  • Multiple posting newcomer
  • *
  • Posts: 32
Re: Code::Blocks slow as molasses
« Reply #2 on: November 28, 2005, 08:55:50 pm »
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

Offline Jorg

  • Multiple posting newcomer
  • *
  • Posts: 32
Re: Code::Blocks slow as molasses
« Reply #3 on: November 28, 2005, 10:11:40 pm »
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
« Last Edit: November 28, 2005, 10:17:08 pm by Jorg »

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: Code::Blocks slow as molasses
« Reply #4 on: November 28, 2005, 11:12:47 pm »
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).

Offline takeshi miya

  • Lives here!
  • ****
  • Posts: 1487
Re: Code::Blocks slow as molasses
« Reply #5 on: November 28, 2005, 11:29:58 pm »
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

  • Guest
Re: Code::Blocks slow as molasses
« Reply #6 on: December 01, 2005, 02:30:52 pm »
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.

Offline takeshi miya

  • Lives here!
  • ****
  • Posts: 1487
Re: Code::Blocks slow as molasses
« Reply #7 on: December 01, 2005, 02:37:16 pm »
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.

Offline Jorg

  • Multiple posting newcomer
  • *
  • Posts: 32
Re: Code::Blocks slow as molasses
« Reply #8 on: December 01, 2005, 03:50:13 pm »
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

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: Code::Blocks slow as molasses
« Reply #9 on: December 01, 2005, 04:33:51 pm »
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: [Select]
    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.

Offline Jorg

  • Multiple posting newcomer
  • *
  • Posts: 32
Re: Code::Blocks slow as molasses
« Reply #10 on: December 01, 2005, 08:40:12 pm »
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

Offline Clojster

  • Single posting newcomer
  • *
  • Posts: 9
Re: Code::Blocks slow as molasses
« Reply #11 on: March 19, 2006, 10:37:42 pm »
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...  :(

Offline Michael

  • Lives here!
  • ****
  • Posts: 1608
Re: Code::Blocks slow as molasses
« Reply #12 on: March 19, 2006, 10:45:14 pm »
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

Offline Clojster

  • Single posting newcomer
  • *
  • Posts: 9
Re: Code::Blocks slow as molasses
« Reply #13 on: March 20, 2006, 09:57:57 am »
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.
« Last Edit: March 20, 2006, 10:03:45 am by Clojster »

Offline Michael

  • Lives here!
  • ****
  • Posts: 1608
Re: Code::Blocks slow as molasses
« Reply #14 on: March 20, 2006, 10:07:31 am »
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

Offline Clojster

  • Single posting newcomer
  • *
  • Posts: 9
Re: Code::Blocks slow as molasses
« Reply #15 on: March 20, 2006, 12:01:52 pm »
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.

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


Of course... everything is smooth and fast. Only this editor has this weird behavior...

And this slowdown persists even when every plugin has been deactivated and c::b restarted...
I really don't know where can be the problem... :/
« Last Edit: March 20, 2006, 12:08:31 pm by Clojster »

Offline Der Meister

  • Regular
  • ***
  • Posts: 307
Re: Code::Blocks slow as molasses
« Reply #16 on: March 20, 2006, 12:33:23 pm »
I remember a bug-report on sourceforge.net that said that this problem is related to the nvidia graphics driver. Unfortunately the bug tracker for the sourceforge-project auf Code::Blocks is disabled, so I can't show you this bug report.
Anyway, I didn't check if this bug could be reproduced. I have a nvidia graphics card (4200TI) and I'm using the nvidia graphics driver (I'm not sure which version I have installed - must be something like 6xxx.) but I don't have such problems. But the editor uses quite a lot CPU-power compared to other editors. But as it is not a problem for me I didn't deactivate this driver to see if the editor uses less CPU-power with another graphics driver.
Real Programmers don't comment their code. If it was hard to write, it should be hard to understand.
Real Programmers don't write in BASIC. Actually, no programmers write in BASIC, after the age of 12.

Offline Clojster

  • Single posting newcomer
  • *
  • Posts: 9
Re: Code::Blocks slow as molasses
« Reply #17 on: March 20, 2006, 12:54:12 pm »
Well, that was me myself who reported that bug. But even when I reported that bug I wasn't sure for 100% if it's related to graphics driver... I'll check it out. And I think that every other text editors works pretty good with this drivers so I wouldn't blame them. I think that bug is in the editor itself...

EDIT: Ok, now I have tested it with standard Xorg's "nv" driver. The problem isn't that markant as with nvidia drivers, but it's there too. CPU usage raises, but typing and moving with mouse has better responsibility with "nv" drivers.
Also by turning off all plugins help in therms of CPU usage while typing and moving cursor above the editor... So I think that responsibility problem might be in nvidia drivers, but that CPU usage is terrible...

What about let the users decide which editor they want to use? (Some option withl list of choices)? I'd prefer VIM (gvim)...
« Last Edit: March 20, 2006, 01:29:54 pm by Clojster »

Offline Der Meister

  • Regular
  • ***
  • Posts: 307
Re: Code::Blocks slow as molasses
« Reply #18 on: March 20, 2006, 02:00:46 pm »
Well, sounds like a nice idea but this would require a common interface for all editors. I'm not sure how much of Code::Blocks depends on scintilla but I don't think that you can just take another editor and replace the old one without at least some changes. I think it should be possible but the problem is: is it really worth the costs? The current editor works quite well (apart from this problem) and I don't believe that most other editors would be better. OK, you said you would prefer VIM. But do you really need it inside Code::Blocks? And how much other users would also choose a different editor? I don't believe that there are a lot of them. And to achive this you must create a common interface for all editors that shall be supported (if this interface is not already there) first and then you have to care about more than just one editor. You have to integrate and test new versions, etc.
As I said, it sounds like a nice idea but I don't think it is worth the costs. Just my opinion and not the opinion of a developer so don't take it into account to much ;)

PS: Sorry for OT...
Real Programmers don't comment their code. If it was hard to write, it should be hard to understand.
Real Programmers don't write in BASIC. Actually, no programmers write in BASIC, after the age of 12.

Offline Clojster

  • Single posting newcomer
  • *
  • Posts: 9
Re: Code::Blocks slow as molasses
« Reply #19 on: March 21, 2006, 12:04:38 pm »
Well ok, I think it would be great to have the possibility of choice :)
Maybe some developer could tell us what he thinks?

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Code::Blocks slow as molasses
« Reply #20 on: March 21, 2006, 12:27:47 pm »
I think it is way out of sight. The benefits are not that big, and integrating another editor would take us several months when in fact the Scintilla component is one of the best editing components in existence and works seemlessly and without any problems for most people.
Actually, it works quite well for many people under Linux, too. I don't know what the problem is in your case, but it might really be a setup problem?

When thinking about the integration of a new default editor, remember that you have to make it work cross-platform, you have to interface with wxWidget's drawing and event system in both directions (how do you do that with VIM without rewriting it from scratch...?), have to take care of things like folding as well as colour and syntax styling (all of these are configurable in the settings), and have to rewrite a lot of code that uses or depends on editor functionality (several plugins and core components).
Sorry, but a massive change like this without absolute need is madness. It takes a lot of work, it is unlikely to improve anything (the opposite is likely), and it is possibly never going to work at all.
If the Scintilla control in the main editor were to be replaced, it should at least be something which is based on wxWidgets, so the event handling and the base interfaces would be compatible.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline DJMaze

  • Multiple posting newcomer
  • *
  • Posts: 32
Re: Code::Blocks slow as molasses
« Reply #21 on: March 21, 2006, 05:48:54 pm »
Scintilla has somesort of bad memory management and this is not C::B related.
I've tested Scite and Notepad2 which both use Scintilla and it gets realy messy on files > 1MB.

For example i opened a 3MB file in Notepad2 and Scintilla popped up a warning box "Are you shure to open this large file"
After clicking yes it took 20 seconds to open the file.
Running a (regex)search took 40 seconds.

In other editors like WinSyntax or UltraEdit i had no issues at all (UltraEdit even 1GB files).

I a haven't looked in the Scintilla source but it seems they only use stack memory which is limited to 1MB per process on windows, or the heap and moving/allocating to much data.

Offline takeshi miya

  • Lives here!
  • ****
  • Posts: 1487
Re: Code::Blocks slow as molasses
« Reply #22 on: March 21, 2006, 06:13:12 pm »
I've tested Scite and Notepad2 which both use Scintilla and it gets realy messy on files > 1MB.

For example i opened a 3MB file in Notepad2 and Scintilla popped up a warning box "Are you shure to open this large file"
After clicking yes it took 20 seconds to open the file.

Sorry I can't confirm that, opening a 50MB file takes less than 3 seconds here in those programs.

What it is a bug in Scintilla is the slowness, that only occurs on GTK on linux and on certain configurations.

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Code::Blocks slow as molasses
« Reply #23 on: March 21, 2006, 06:36:08 pm »
No offense, but this is plain bullshit. I just edited a 37.5 MB file with 494,000 lines in Code::Blocks to verify this claim. The same block of lines copied and pasted many times, then saved to disk.

On my machine, opening such a ridiculously big file takes about 8-9 seconds, and there is a lag of about half a second while editing. Cutting 50 lines from the middle of the document and pasting in another place (arbitrary position) takes no longer than half a second, either.
Deleting the first 1,000 lines from this document takes about a second. Deleting the next 10,000 lines (after the first 1,000) takes about 12 seconds. Saving that document takes about 3 seconds.
Editing a 2.2 MB file (which is still outright ridiculous) has no noticeable delay at all (cutting and pasting a block the size of about 50% of the text takes under a second).

Similar figures for SciTE, except that SciTE has no noticeable lag at the beginning of arbitrarily large documents (to be honest, I only verified "arbitrarily large" with a 80 MB document). Instead, editing gets delayed only at the end of the document. However, for any reasonable document size (under 5 MB), there is no noticeable delay at all.

How can you call this "bad management"? Honestly, I could not possibly write an editor that performs any better than this (or which even gets near that). Can you?

If you seriously consider editing source files whose sizes are on the order of several megabytes, you have a problem. It is not your editor, though...


EDIT: I forgot to mention that the above numbers include the overhead for the code completion parser, which consumes massive CPU and memory, too. And yet it still works acceptable at file sizes that are really unrealistic (whose source files are >2 MB?).
« Last Edit: March 21, 2006, 06:44:29 pm by thomas »
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline DJMaze

  • Multiple posting newcomer
  • *
  • Posts: 32
Re: Code::Blocks slow as molasses
« Reply #24 on: March 21, 2006, 06:45:12 pm »
Hmmm then it's probably something bad in my computer then when you guys don't have that lag.

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2119
Re: Code::Blocks slow as molasses
« Reply #25 on: March 21, 2006, 09:24:35 pm »
Hmmm then it's probably something bad in my computer then when you guys don't have that lag.

I serviced medium and large computer network organizations for
for over 20 years. Inevitably, compaints of this type turned out to be
the video driver. Once upgraded/replaced, the problem went away.

Offline SirMike

  • Multiple posting newcomer
  • *
  • Posts: 10
Re: Code::Blocks slow as molasses
« Reply #26 on: April 28, 2006, 07:26:14 pm »
I have a similar problem on my Slackware Linux. Also with all plugins disabled. Tried it with, KDE and fluxbox - the same result on both. Other apps work fine (like SciTE) so it must be a C::B problem :( I need to use Vim again instead of my favourite IDE

My PC is Sempron 2800+, 1GB RAM, GF6600
« Last Edit: April 28, 2006, 08:05:59 pm by SirMike »

Offline Michael

  • Lives here!
  • ****
  • Posts: 1608
Re: Code::Blocks slow as molasses
« Reply #27 on: April 28, 2006, 09:02:12 pm »
I have a similar problem on my Slackware Linux. Also with all plugins disabled. Tried it with, KDE and fluxbox - the same result on both. Other apps work fine (like SciTE) so it must be a C::B problem :( I need to use Vim again instead of my favourite IDE

My PC is Sempron 2800+, 1GB RAM, GF6600

Hello,

Which C::B revision are you using? If RC2, try to build C::B from the SVN sources.

Anyway, I am not sure that it is a C::B problem. I use C::B on Ubuntu and my PC is Pentium III 500MHz with 500MB RAM. C::B is slow as any other applications I use. IMHO your problem is not dependent on C::B (not directly anyway).

Best wishes,
Michael

Offline SirMike

  • Multiple posting newcomer
  • *
  • Posts: 10
Re: Code::Blocks slow as molasses
« Reply #28 on: April 29, 2006, 12:33:39 pm »
Which C::B revision are you using? If RC2, try to build C::B from the SVN sources.
Anyway, I am not sure that it is a C::B problem. I use C::B on Ubuntu and my PC is Pentium III 500MHz with 500MB RAM. C::B is slow as any other applications I use. IMHO your problem is not dependent on C::B (not directly anyway).

I use yesterday's SVN revision compilation. I installed SciTE and this problem doesn't exist there.
I'll try newer drivers for my graphic card and let you know what happen.

// EDIT - The newest drivers for my GF6600 didn't affect performance. I also noticed interesting fact - In MinGWStudio for linux, which also uses scintilla the problem occurs too. Weird :| Is it any feature that I can disable to test them more?
« Last Edit: April 29, 2006, 12:54:22 pm by SirMike »

Offline takeshi miya

  • Lives here!
  • ****
  • Posts: 1487
Re: Code::Blocks slow as molasses
« Reply #29 on: April 29, 2006, 01:41:39 pm »
Ok, more than one people have reported slowness when using:
-Code::Blocks (wxScintilla+wxWidgets) [Scintilla+GTK]
-wyoEditor (wxScintilla+wxWidgets) [Scintilla+GTK]
-MinGW Studio (wxStyledTextCtrl+wxWidgets) [Scintilla+GTK]

and it doesn't happens in SciTE (Scintilla+GTK).

So, there are high chances that it's a wxScintilla/wxSTC bug, or a bit less-likely, wxWidgets.

More testers? Profiling?

Offline SirMike

  • Multiple posting newcomer
  • *
  • Posts: 10
Re: Code::Blocks slow as molasses
« Reply #30 on: April 29, 2006, 01:50:50 pm »
I can also add that tested those apps with disabling any possible options related to editor.

Offline takeshi miya

  • Lives here!
  • ****
  • Posts: 1487
Re: Code::Blocks slow as molasses
« Reply #31 on: April 29, 2006, 02:13:52 pm »
SirMike: could you try to profile Code::Blocks?

Offline SirMike

  • Multiple posting newcomer
  • *
  • Posts: 10
Re: Code::Blocks slow as molasses
« Reply #32 on: April 29, 2006, 02:43:37 pm »
SirMike: could you try to profile Code::Blocks?

Sure - cannot do it right now but I'll try as soon as I'm back at home.

Offline SirMike

  • Multiple posting newcomer
  • *
  • Posts: 10
Re: Code::Blocks slow as molasses
« Reply #33 on: April 29, 2006, 04:56:50 pm »
OK, I recompiled C::B with -pg and ran gprof.

I just fired C::B, wrote simple program (like Hello World with some functions) copied some text, scrolled several times.

You can find the result in an attached file.

[attachment deleted by admin]

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Code::Blocks slow as molasses
« Reply #34 on: April 29, 2006, 05:24:18 pm »
For such profiling to be effectively usable, you have to disable all plugins and scroll for a long time (20-40 seconds). For profiling to be valid, the thing you want to measure must be isolated as much as can be done.

Otherwise, the CPU time that goes into startup (loading plugins, config, lexers) skews the measuring beyond any good use. Imagine what happens if the code parser runs over your source while you scroll. What will appear in the profile?
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline SirMike

  • Multiple posting newcomer
  • *
  • Posts: 10
Re: Code::Blocks slow as molasses
« Reply #35 on: April 29, 2006, 06:04:07 pm »
Weird, I did more scrolling and typing but results are almost the same this time :|

[attachment deleted by admin]

Sherwood

  • Guest
Re: Code::Blocks slow as molasses
« Reply #36 on: May 06, 2006, 02:34:08 am »
I have had the same speed problem with debian etch.
I don't think it's a Code::Blocks problem: The SAME .deb I used in debian etch works fine on Ubuntu 5.10 (which I just installed).

The problem must be in a new version of a Code::Blocks dependency (wx, provably).

We could isolate the problem, trying with increasing versions of the libraries used by Code::Blocks...
I know, that's a pain in the ass, but...

- SW

By the way, this one is the nicets IDE I know! Keep going!