C::B : a CPU consumer ?

[Rockeye]

Hi !

It seems that C::B always consumes CPU time...

On a Athlon XP mobile 1800+, it uses approximately 1% for 80% of the time, but reaches some peaks at 23% sometimes !! These measures were done at the welcome screen, but with an opened project with no file opened, it is the same.

With a project of 20 files, and 7 files opened (4 .cpp, 3 .h), the CPU time required by C::B is often over 35%  :shock: and reaches sometimes 70% ... The fact that the application is minimized or not doesn't affect these results.

Why an IDE need such computation power Is it a bug in a fonctionnality ?

My C::B : revision 3145 nightly build 25 oct. 2006

Note : it is not due to this revision, I have observed this since I adopt C::B, three month ago.

[DonSixto]

I'm sorry to tell you that you are out of place.
This post offends me.
If your computer is for c++ programming, then what is the problem to spend 35 to 70% of the processor time for what your are supposed to do ?
or better, for what you are paid for ?
If you are under windows and you are programming in the same computer where the data server is running, then you are doing things wrong. You can't do this under windows, even in server 2003.
Ask your boss to buy another one.
It is not the same in linux, you can do programming and data serving in linux.
And let me tell you that I know what I'm talking about, because I'm a c++ programmer since 14 years ago.
I fed my children from my c++ programming jobs.

I repeat, this post offends me.
Feel free to ban this.

[Ceniza]

One of Code::Blocks' most known issues is the high CPU usage when you move the mouse around, and it should have a high CPU usage while the CodeCompletion plugin is parsing too. If you don't touch it and CodeCompletion is done, it should not take that much CPU.

Right now I have Code::Blocks opened with the Code::Blocks project loaded, all plugins loaded and CodeCompletion done parsing and the CPU usage is 0%.

If I start moving the mouse around I get about 30% CPU usage (and since it's a HT CPU you could say it's twice, 60%). I stop moving the mouse and get 0% again.

It seems to be related to the bunch of EVT_UPDATE_UI in the code and there is not a solution for it right now.

Could you check if the problem I'm describing is the one you're getting?

[TDragon]

And let me tell you that I know what I'm talking about, because I'm a c++ programmer since 14 years ago.

Impressive as your resume may be, Rockeye has a point. If one compares the CPU usage of Code::Blocks when idling to that of similar programs, such as Eclipse or OpenOffice, it's higher than expected.

Any possible reason to find Rockeye's post offensive escapes me. Instead of attempting to refute the invalid assumptions and blatant misinformation DonSixto's post contains, I'll simply agree with Ceniza in saying that the issue in question is undesirable, but can't currently be remedied.

[Game_Ender]

That and it sucks up the cycles on Linux like crazy while I type, not enough to make it so I can type faster the screen updates but enough to create an uncomfortable feel.

[Commodore64]

I'm sorry to tell you that you are out of place.
This post offends me.

I don't agree at all with you.

First, I don't see why a program should employ more CPU time than what it needs. I'm not saying that C::B takes too much CPU time; but, as a general rule, less is better

One reason why a lower CPU usage is desirable is power. This summer I have been programming with C::B in a nice mountain place, under the wood with my laptop... well, I wanted to maximize my battery's life, and I wasn't too happy that, almost every time I scrolled code, the frequency and voltage of my CPU were increased by the CPU driver, and the CPU fan turned on...

And I don't like general statements like "if you are using a Windows 2003 as a data and application server, you are doing wrong". Who says that? And why cannot I use, for example, a Windows 2003 machine as a terminal server with many programmers logged in, doing their job with C::B? Why should I always buy underutilized new hardware if old hardware can do the job well?

[Rockeye]

I'm sorry to tell you that you are out of place.
This post offends me.

 :shock: :shock: :shock:
You are shocked because an idle IDE consumes CPU time

I was just curious, and wonder if it is a well known issue or a bug in my laptop.

As Commordore64, I am working on a laptop and I pay a great attention to the CPU consumption. I expect an idle appplication such as notepad to not use ANY CPU time. And C::B is an extended Notepad when idle (sorry for developpers, don't be offended, you do a great IDE  ).

C::B uses cpu even when all parsing processes and others are terminated, neither compilation, nor debug running. So I wonder : "Why ?"

Is it an isolated case or other users are concerned ?

>Ceniza : The mouse is not involved in my case because when C::B is minimized with a project open and several files (7) opened in the editor, it consumes at least 10%...

[tiwag]

C::B uses cpu even when all parsing processes and others are terminated, neither compilation, nor debug running. So I wonder : "Why ?"

make a cpu load diagram using process-explorer or any similar tool,

when i do this, i can see that CB doesn't have any cpu load (after the initial file loading, code parsing, etc...) when CB is minimized  :?




brgds

[DonSixto]

I don't agree at all with you.

I am sorry if I bothered.

First, I don't see why a program should employ more CPU time than what it needs. I'm not saying that C::B takes too much CPU time; but, as a general rule, less is better

Yep, you are right.
I think it's just a matter of time, and developers will improve C::B the way you want.
But in the meantime, how about making a donation ?
It would encourage them to do so.
I am happy with current version.
I will have to donate.

And I don't like general statements like "if you are using a Windows 2003 as a data and application server, you are doing wrong". Who says that? And why cannot I use, for example, a Windows 2003 machine as a terminal server with many programmers logged in, doing their job with C::B? Why should I always buy underutilized new hardware if old hardware can do the job well?

I say so.
You misunderstood me in this point.
I found that when you have a data server deamon that uses tcp/ip in win srv 2003, when it is serving several requests and generates more than a million packets in a matter of minutes, if you compile something in the same computer somehow the windows loses packets, causing undesirable results.
And I found too that an old computer, say a pentium iii 500 mhz with 256MB, performs very well for c++ development with C::B and other IDEs too.
But what I definitely can't do is data serving and compilations in the same windows computer. The other employees complain because they notice the server too slow. And they are right to complain. They have the customers in front of them and the attention should be quick and of the best quality.

Once more, I'm sorry if I bothered.
Sometimes, something may be offensive to me if it is written in certain way.
And more when it's about a very good open source tool that I'm happy to be able to use.
My apologies to you all.

Kind regards.

[Commodore64]

I think it's just a matter of time, and developers will improve C::B the way you want.

Yep, nothing is perfect in this world   
But if we all are using Code::Blocks, it is because we find it "more" perfect than the competition 

I found that when you have a data server deamon that uses tcp/ip in win srv 2003, when it is serving several requests and generates more than a million packets in a matter of minutes, if you compile something in the same computer somehow the windows loses packets, causing undesirable results.
And I found too that an old computer, say a pentium iii 500 mhz with 256MB, performs very well for c++ development with C::B and other IDEs too.
But what I definitely can't do is data serving and compilations in the same windows computer. The other employees complain because they notice the server too slow. And they are right to complain. They have the customers in front of them and the attention should be quick and of the best quality.

You're right, Windows is all but perfect  :lol: even if one would expect something more, given its cost and its level of sophistication.
However, I think that anybody should be free to try and use the solution more suitable to its needs... I'm not an expert, but I think that an application server with Windows Server 2003 can manage a reasonable number of users programming concurrently (if it is not used as a data server... as you say!)

[thomas]

While it is true that CPU consumption is sub-optimal in some cases, Code::Blocks performs by order of magnitude better than for example Eclipse (the latter was mentioned above) in almost every respect.

The three cases which I personally find inacceptable are typing, moving the mouse, and of course my special friend code completion. Moving the mouse and typing eats up 3-4%, resp. 12-20% CPU time on my machine. While I am not afraid of burning a few cycles, it just seems to be by order of magnitude too much. 3-4% load average measured over a 1-second interval translates to around 8-10 million CPU instructions on my machine (assuming a per-instruction latency of 6-8 cycles). That seems quite a lot for just pressing a key...
Unluckily, we will not be able to address this issue any time soon, as it is dependent on wxWidgets message handling and frequent, redundant UI updates. This will get significantly better with the action manager system, but it won't completely eleminate the problem either (as a considerable part of it is beyond our control).
Regarding my special friend code completion, I have to admit that parsing is a CPU-intensive task, so well... it still annoys me, but I think it is justifiable, and blaming it for eating up CPU would be quite silly.

However, regarding idle CPU consumption, I think that I have to object that your assessment is somewhat unfair. Code::Blocks does not consume any significant amount of CPU time when being idle. To be precise, on my machine, it takes exactly 0.0% CPU.

Please do note that the nightly builds that most everybody uses come with a huge collection of plugins many of which *do* consume CPU time. I stronly assume that this is what actually causes your issue.
However, you cannot blame Code::Blocks for that.


Note: the following paragraph is exemplary and is not meant to disgrace one particular plugin. Several other plugins consume CPU time in similar ways.

KeyBinder registers to wxWidgets idle events. The amount of work done inside OnIdle() does not look very significant at first. Basically, wxDateTimeis used to count up to 15 seconds to perform some more expensive work.
So, where is the beef? The number of idle events that wxWidgets sends out is proportional to the cursor blink rate and proportional to the number of open editors! Seriously!
If you think I am joking, then insert a counter into OnIdle(). When you open a dozen or two documents, you will see that OnIdle is it is called roughly 30-50 times per second. This is of course not a problem for a modern Processor, but it explains why you may see 1-2% CPU usage when actually nothing happens at all.
Neither wxDateTime::Now() nor wxDateTime::Subtract() are trivial function calls that take only a handful of instructions. Clearly, calling them many times per second will eventually consume noticeable CPU time. Also, the above is only one example.

Is this a bug that should be fixed? Unconclusive... it sure is annoying when your fan goes up all the time, and this particular example would be better implemented using a timer, sure enough.
However, on the whole scale, this is a fight against windmills. Many of the issues that we are facing in our application are really problems of wxWidgets.

[Rockeye]

However, regarding idle CPU consumption, I think that I have to object that your assessment is somewhat unfair. Code::Blocks does not consume any significant amount of CPU time when being idle. To be precise, on my machine, it takes exactly 0.0% CPU.

Take a look at this :


1 : CB loading
2 : CB parsing (project opened with 10 files opened in the editor)
3 : CB is minimized. The peak is due to the click
4 : CB is shown
5 : CB is minimized

I have done these measures without mouving the mouse in CB (or the minimum), so, keys or mouse are not involved...

When minimized, CB consumes in average 7.5%, and when shown 10%....

Moving the mouse and typing eats up 3-4%, resp. 12-20% CPU time on my machine.

Indeed, that why I measured some peaks in my first post stats.

It seems that i am the only one who has this issue... It may came from my computer (Athlon XP 1800+ Mobile) !
If any one has the same problem, please support me ! I feel so alone in this topic. People don't believe me !!!! bouhouhou....

[tiwag]

please try disabling plugins and do measures again,

i've enabled almost all plugins but wxSmith



brgds

[Pecan]

I'm not ready to put all the blame on CB.
On my XP Dell 9300 1.8mhz, leaning on the mouse eats 3-4% without CB even loaded.
With CB loaded and minimized, I get 0% cpu usage.

[Pecan]

KeyBinder registers to wxWidgets idle events. The amount of work done inside OnIdle() does not look very significant at first. Basically, wxDateTimeis used to count up to 15 seconds to perform some more expensive work.
So, where is the beef? The number of idle events that wxWidgets sends out is proportional to the cursor blink rate and proportional to the number of open editors! Seriously!
If you think I am joking, then insert a counter into OnIdle(). When you open a dozen or two documents, you will see that OnIdle is it is called roughly 30-50 times per second.

Note that, unless you do something specifically, the idle events are not sent if the system remains idle once it has become it, e.g. only a single idle event will be generated until something else resulting in more normal events happens and only then is the next idle event sent again.

Oh Well; I guess docs versus real world strike again. I chose wxIdleEvent only because I thought (from the docs) that it was going to be the most efficient and enter the code less than a timer would.
I tested using a log write, and noticed that on some occasions it enter the code only every 30 seconds or so. Guess I didn't test enough.
On my way back to the closet to rethink the implementation.

[Rockeye]

please try disabling plugins and do measures again,
i've enabled almost all plugins but wxSmith

It is exactly the same results : CB uses 10% of cpu...

I'm not ready to put all the blame on CB.

Actually, I can't put the blame on CB because it appears that i am the only one with this problem... But it could be an incompatibilty between CB and some kind of processors (in my case AMD AthlonXP Mobile )
Does anybody have an AMD laptop in here ?
As I said before, I pay a great attention to the cpu consomption because of my laptop batterie life, so I often check the processes' cpu usage, and CB is the only one who do that... I can suppose there is a set of instruction that are not (or badly) managed by my processor (or perhaps motherboard, i dont know).

[thomas]

Oh Well; I guess docs versus real world strike again. I chose wxIdleEvent only because I thought (from the docs) that it was going to be the most efficient and enter the code less than a timer would.

Pecan, don't worry about it. As I said: I do not mean to disgrace Keybinder as such, the above was exemplary, some other plugins do similar stuff. It just so happens that I knew some were using OnIdle, and I did a global file search, and the first hit was KeyBinder

One should think that OnIdle is really something that does not use up CPU, but that's not the case (at least not with any textedit or Scintilla controls open). Also, one should think that it doesn't matter whether you call a more or less expensive time function, since it's only called very rarely anyway. However, the amount of time OnIdle is called seems to be directly proportional to the number of editors (and caret blink frequency), which is kind of crazy in my opinion. That's not a problem of yours, though... it's wrong from the side of wxWidgets.

The thing is really that the documentation is often far from reality and many problems that show up in our code are really wxWidgets quirks (or bugs). You're fighting windmills if you try to address every problem.

[Alpha]

Something curious I noticed is that Code::Blocks' CPU usage drops to zero if you click on a menu (like File), and leave the mouse hovering there.  Perhaps something in this can be exploited for optimization on older computers?

[thomas]

Something curious I noticed is that Code::Blocks' CPU usage drops to zero if you click on a menu (like File), and leave the mouse hovering there.  Perhaps something in this can be exploited for optimization on older computers?

That's not something special, it is what happens in most message-driven GUI environments.

While CPU usage is zero, it also means you can do zero useful things. The main thread is not pumping messages, and no application callbacks are called.

[Alpha]

Yes, but if Code::Blocks can be (optionally) put into this state during compilation, it will result in 10-20% shorter compile times on older computers.

(I have tested by leaving the mouse inside a menu while building a project.)

[MortenMacFly]

Yes, but if Code::Blocks can be (optionally) put into this state during compilation, it will result in 10-20% shorter compile times on older computers.

Maybe I mis-understood, but if during compilation you go into idle code than this means C::B would not handle any messages coming from the compiler. While this is technically not possible without major rewrite of some portions it is also not meaningful, because you would never get displayed any messages from the compiler...?!

[Alpha]

I think last time when I tested, there must have been some strange fluke (??!), because I did receive a speedup.  However, you a right, I just re-tested, and found the compilation halts until I leave the menu.

(I wonder what happened last time...)

[thomas]

Without receiving messages, how do you know the compilation is finished?

[MortenMacFly]

Without receiving messages, how do you know the compilation is finished?

Without output re-direction events to be more precise. Surely you'll need to listen for a "task / command completed" event. However - although it might be possible it still doesn't make sense.

[thomas]

Well, the thing is, if you put an application into "block inside GUI" mode, it does just that. Or, at least its window thread does that. If the main thread and the window thread are the same (as is the case with Code::Blocks), this means the application does nothing in the mean time.

Try this for yourself, make a new OpenGL project using the wizard, this will build the classic, well-known "spinning triangle" demo. Very fancy to look at.

The demo does nothing but draw a spinning, colored triangle as fast as it can, and pump messages in between, so the application works in a "normal way" (i.e. it does not show the "application is hung" dialog, and the window can be dragged and closed).

Now click on the system menu or drag the window. And behold, the triangle stops spinning. CPU usage is zero, but also the application is not doing anything.