Author Topic: Code::Blocks Performance !!  (Read 4673 times)

Offline boaz

  • Multiple posting newcomer
  • *
  • Posts: 18
Code::Blocks Performance !!
« on: February 28, 2006, 10:21:45 pm »
If I compile a project like wxWidgets2.6.2 with Mingw3.4.4 which means lots and lots of warnings, than looking in Task Manager I see g++ taking 3%-5% CPU and C::B itself taking 95% (no kidding :shock:). Needless to say that it is 10 times slower than to fire a CMD and do mingw32-make

I use an external makefile, PIII 1Gz with Intel-On-chipset Display adapter. OK not so strong, but 95/5 IDE/compiler is really bad. MSDEV on the same machine with same amount of errors does 7/93 IDE/compiler.

Could someone check on other machines/projects?
What you guys think??

Free Life
Boaz

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: Code::Blocks Performance !!
« Reply #1 on: February 28, 2006, 10:48:13 pm »
What version of Codeblocks are you using?

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Code::Blocks Performance !!
« Reply #2 on: February 28, 2006, 11:36:44 pm »
On my system, Code::Blocks takes about 3-5% CPU time.

What you are seeing is probably because you start a compile while the code completion plugin is still parsing. When working on something the size of wxWidgets in Code::Blocks, parsing can take a while if you have globals enabled...

This is very disadvantageous for three reasons:
- parsing and compiling fight over hard disk access
- parsing and compiling fight over the CPU
- parsing takes a lot of memory, and so does compiling (especially with PCH)
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline boaz

  • Multiple posting newcomer
  • *
  • Posts: 18
Re: Code::Blocks Performance !!
« Reply #3 on: March 01, 2006, 12:43:40 am »
I'm using Feb 23

No It is definitely the std-output. I just did clean, the CPU is at 0% I press "build" button. At the beginning WX compiles some C files, no errors, CB is at 3-6%. Once it gets to cpp files and the
"warning: type attributes are honored only at type definition"
Than CB CPU goes to 90%+.

(is there a gcc switch to turn that warning off?)


Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Code::Blocks Performance !!
« Reply #4 on: March 01, 2006, 12:48:36 am »
-w
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline boaz

  • Multiple posting newcomer
  • *
  • Posts: 18
Re: Code::Blocks Performance !!
« Reply #5 on: March 01, 2006, 12:58:13 am »
I was looking at compilergcc.cpp to see why the stop does not work. It does a wxKill which does an EnumWindows, needless to say that that will never work on redirected consol application like GCC. Well I was thinking that, the all thing could be done with popen (_popen in msvc) it works very fast, and reads could be done full lines at a time. Also the "terminate" is easy and I even think you can send ctrl+c through it. This is also very Unix portable. I'll make some test.

That or Intel's VGA sucks big time

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Code::Blocks Performance !!
« Reply #6 on: March 01, 2006, 09:27:11 am »
Don't waste your time, we have tried popen many months ago. It is fine for Linux, but it won't do for Windows.

Stop does work. Within the operating system's capabilities.
Your objection regarding wxKill is correct, but that is a known Windows problem. Windows does not support any such thing as SIGTERM (which would be the right thing to use in this place). The only alternative would be to use SIGKILL, that would certainly end the process, but this is not an option, for obvious reasons.
Under Linux, the stop button works as you expect it, because SIGTERM is used.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline boaz

  • Multiple posting newcomer
  • *
  • Posts: 18
Re: Code::Blocks Performance !!
« Reply #7 on: March 01, 2006, 10:38:48 am »
Don't waste your time, we have tried popen many months ago. It is fine for Linux, but it won't do for Windows.

It works fine in msvc++ implementation from msvcrt.dll. The GCC implementation I never tried.

Quote
Stop does work. Within the operating system's capabilities.
Your objection regarding wxKill is correct, but that is a known Windows problem. Windows does not support any such thing as SIGTERM (which would be the right thing to use in this place). The only alternative would be to use SIGKILL, that would certainly end the process, but this is not an option, for obvious reasons.
Under Linux, the stop button works as you expect it, because SIGTERM is used.

I don't see how it can work. The code Does an EnumWindows() looking for which Window has the passed PID. Now GCC or mingw-make has no Window, so it is not enumerated. and is never sent any signals.
If you have built-in project than all pending files are flushed and the build stops after the current file, fine. But on an external Make. Nothing is actually done.

Offline boaz

  • Multiple posting newcomer
  • *
  • Posts: 18
Re: Code::Blocks Performance !!
« Reply #8 on: March 01, 2006, 10:47:35 am »
Quote
Windows does not support any such thing as SIGTERM

what about GenerateConsoleCtrlEvent(CTRL_BREAK_EVENT ,consolProcessID);

more signals are:

#define CTRL_C_EVENT               0
#define CTRL_BREAK_EVENT        1
#define CTRL_CLOSE_EVENT        2
// 3 is reserved!
// 4 is reserved!
#define CTRL_LOGOFF_EVENT      5
#define CTRL_SHUTDOWN_EVENT 6

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Code::Blocks Performance !!
« Reply #9 on: March 01, 2006, 11:23:50 am »
I have never used that function, but MSDN talks about "a console process group that shares the console associated with the calling process".
This means (if I read it correctly) that the IDE and the build tools would have to share one console for this to work. That is of course not acceptable since an abnormal termination of a compiler process might terminate the IDE too, in that case.

Nevertheless, I may of course be wrong, feel free to make a patch for wxExecute and submit it to wxWidgets. It is a very platform-dependent thing, so any modifications should go into wxWidgets.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."