C::B : a CPU consumer ?

[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.