User forums > Using Code::Blocks
C::B : a CPU consumer ?
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:
--- Quote ---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.
--- End quote ---
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%....
--- Quote ---Moving the mouse and typing eats up 3-4%, resp. 12-20% CPU time on my machine.
--- End quote ---
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:
--- Quote from: thomas on October 26, 2006, 06:17:05 pm ---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.
--- End quote ---
--- Quote from: wxWidgets Documentation ---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.
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version