News:

As usual while waiting for the next release - don't forget to check the nightly builds in the forum.

Main Menu

It seems CB will hang about 10+ seconds to load the codeblocks.cbp project

Started by ollydbg, January 05, 2010, 04:40:07 AM

Previous topic - Next topic

ollydbg

Windows XP, SVN 6048 self build version(TDM GCC 4.4.1-2).
Does someone encounter the same problem?
Thanks
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

MortenMacFly

Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: [url="https://www.codeblocks.org/docs/main_codeblocks_en.html"]https://www.codeblocks.org/docs/main_codeblocks_en.html[/url]
C::B FAQ: [url="https://wiki.codeblocks.org/index.php?title=FAQ"]https://wiki.codeblocks.org/index.php?title=FAQ[/url]

vix

QuoteDoes someone encounter the same problem?
I have the same problem. The old svn 5911 works well.
I noticed that during this seconds the C::B CPU load is very high (more than 50%).

If you open C::B the program hangs for 5-6 seconds with high CPU load before you can start working. SVN 5911 works well.

Loaden

Yes, I have such a feeling. And my side of the CB users, are also reflected in very slow start-CB!

Loaden

I think that the CB at boot time to load too many wizard, which in fact is unnecessary!
Now, CB boot speed is not much faster than the Eclipse CDT!
Even slower than the VS!

blueshake

Keep low and hear the sadness of little dog.
I fall in love with a girl,but I don't dare to tell her.What should I do?

Jenna

Does this happen just after starting blank C::B  ?

Please start it with -d form commandline to get the debug-output.
You might have to start C::B, go to the Code::Blocks debug panel in the logger-pane, close C::B and open it again, to make sur that you can see the debug log while starting.

I hope it works, because on my XP, the content of the log is not visible without scrolling it a tleast one time.

To make sure it's a plugin, you can disable them all and reenable them one after the other, or disable them one after the other, to see whether one of the plugins slows down C::B.

By the way I have no such issue on my XP box.

vix

I don't think it's a problem of too many plugins because I have only the default ones (no additional ones).

QuotePlease start it with -d form commandline to get the debug-output.
You might have to start C::B, go to the Code::Blocks debug panel in the logger-pane, close C::B and open it again, to make sur that you can see the debug log while starting.
I verified that when C:B hangs, the last line of the debug panel is
Caching internal gcc dirs for adding to parser...

After some seconds the following lines appear
Caching GCC dir: c:\programmi\MinGW\lib\gcc\mingw32\4.4.1\include\c++
Caching GCC dir: c:\programmi\MinGW\lib\gcc\mingw32\4.4.1\include\c++\mingw32
Caching GCC dir: c:\programmi\MinGW\lib\gcc\mingw32\4.4.1\include\c++\backward
Caching GCC dir: c:\programmi\MinGW\include
Caching GCC dir: c:\programmi\MinGW\lib\gcc\mingw32\4.4.1\include
Caching GCC dir: c:\programmi\MinGW\lib\gcc\mingw32\4.4.1\include-fixed

and C::B is ready to operate

QuoteTo make sure it's a plugin, you can disable them all and reenable them one after the other...
I tried, and the problem is in the "Code Completion" plugin.
If I enable only this one the problem happens. If I enable all the others, the problem doesn't happen.

I don't know if this helps, but I have C::B on C: drive, and the *.cbp, and workspaces on a different logical drive (D:\), that is a different logical partition on the same physical drive as C: