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.
