Code::Blocks is really slow. How do I fix it?

[indietom]

I've been using code::blocks for like a year without problems but recently code::blocks has been running really slow. If I minimize the window and open it up it takes like 30 seconds until it's usable and if I type code::blocks freezes and then the text shows up and no other program I use acts like this. Is there any way to fix this?
Could it have something to do with the fact that I only have 17 gig left on my hardrive or is there a program that is know to interfere with code::blocks?

Thanks for any help.

[BlueHazzard]

Codeblocks Version?
OS?
How big is the project?
CPU usage of C::B?
How big are the codefiles?

[indietom]

Oh, maybe I should have added more info. I'm running version 12.11 on windows 7. I only have 9 files and about 1900 lines of code.

[BlueHazzard]

CPU usage of C::B?

does it slow down on every project or only with one?

[stef1]

Recently I experienced C:B being very slow after Code Completion plugin enabled.
I do not know we are sharing the same problem but here is what I learned:

Recently I experienced major slow down with my C:B. After investigating it turned out the performance problem is related to the Code Completion plugin. After further investigation I was able to locate the root cause of the problem which was in the .cbp file using relative (to the .cbp location) path to the source code files location in the project.
As a workaround I edited the .cbp file and replaced all the path referenced to absolute path and this fixed the performance problem.
The problem started when I decided to keep all my C:B project files in one folder external to all my existing projects.
I would like to know if anybody else experienced such problems and if there is a way to instruct C:B on the project creation to use absolute location for the source code files.

[ollydbg]

...
Recently I experienced major slow down with my C:B. After investigating it turned out the performance problem is related to the Code Completion plugin. After further investigation I was able to locate the root cause of the problem which was in the .cbp file using relative (to the .cbp location) path to the source code files location in the project.
...

If this is the reason, then this bug should be fixed. But I don't have such experience in my system(WinXP, Latest Nightly build).

[Wyrm]

I also run into occasional slowdowns during code editing. My platform: Linux Mint 14 with KDE, C::B version 12.11 compiled from source on Dec 8 2012,
I never bothered reporting it though because my C::B version is kinda old. On top of it, there is always an opportunity to save everything and restart C::B with no problems.
That said, I am not willing to sacrifice relative paths. I often need to work with several branches and I don't want to hard code absolute paths in project files. I'd rather restart C::B.
-W

[Pecan]

As a curiosity, could you tell us what your Symbols tab "View:" setting is.

It will be one of the following:

Current files symbols
Current projects symbols
All local symbols
Everything

[stef1]

In my case the Symbols tab is set to Current file's symbols.

[Pecan]

Change the setting to "Current Project's symbols" and see if the problem goes away.

ImageCraft found a quirk in CalculateCommonTopLevelPath() which sets the top level path to the root of the hard drive. This causes CodeCompletion to start all searches from the root of the hard drive. You might have hit this problem.

[ollydbg]

Change the setting to "Current Project's symbols" and see if the problem goes away.

ImageCraft found a quirk in CalculateCommonTopLevelPath() which sets the top level path to the root of the hard drive. This causes CodeCompletion to start all searches from the root of the hard drive. You might have hit this problem.

What does "ImageCraft" means? Does it mean this IDE https://www.imagecraft.com/ ? It looks its a C::B fork?


EDIT:
In the page: https://www.imagecraft.com/devtools_AVR.html

I see such statement:

The V8 products use CodeBlocks as the IDE. Per GPL requirements, you may download the modified source code (trunk SVN8162) here. http://imagecraft.com/pub/ICC_CB_SVN8162.7z

[Wyrm]

I had another one of those slowdowns. Switching symbol settings didn't help, and my symbol list was only about 20.
In fact, not just the editor, everything became slowish. Switching to another tab - half a second delay. Moving separator - half a second delay. Switching from projects to symbols - a second delay.
In addition, I started having visual artifacts, a rectangle from another part of the code kept hanging around. To get to this point I kept C::B open for about 2 days without a restart.
Top showed that Xorg CPU usage shot up to 80% and Kwin started showing up high on top as well. Xorg lingers at the top of the CPU usage (in the range of 50% - 80%) for about 10 seconds if I don't touch C::B and then gradually goes down to single digits. Whenever I try to do anything in C::B Xorg CPU usage would go up again.
I have a 7MB video of this slowdown. Unfortunately, the mouse pointer is not recorded, so it is hard to judge the delay from the video.

Edit: my system and C::B version are listed in the previous post.

[ollydbg]

@Wyrm
Is it possible to post your testing project and the steps here?
Because without this, other one can not reproduce this bug. Thanks.
BTW: I can help to test on Windows system.

[Wyrm]

@Wyrm
Is it possible to post your testing project and the steps here?
Because without this, other one can not reproduce this bug. Thanks.
BTW: I can help to test on Windows system.

Thanks for the offer. Let me first try to troubleshoot it on my side. Besides, I'm not sure if it is reproducible on a Microsoft platform. If it is an X-windows resource leaking then it's unlikely that you'll see it.
The steps I want to take are these:

• I need to upgrade my C::B anyways. It's compiled with Dec 9, 2012 source code. The newer version may not exhibit this problem.
• When I compile the new source I'll add "-g" to the release build to include debug symbols.
• If the new version gets slow I'll attach one of my debuggers to it and get a handful of stack traces. I also have access to some commercial debuggers and profilers which may help to investigate this.

So far I've been delaying this exercise because a simple restart fixes all problems. We all work with tight schedules and it's hard to justify major time investment when 3 seconds is all it takes to work around the issue. I will try to get to it in the next couple of weeks.