User forums > Using Code::Blocks

High CPU usage

<< < (6/11) > >>

thomas:
It gets more surprising...

Before modifying and recompiling anything, I started doing some timings on my own machine this morning.
a) RC1-1 as downloaded from the Code::Blocks site

* With all standard plugins (plus my own), it uses 36-63% CPU (average ~55%) while moving the mouse over the editor. The spread (42%) is simply amazing, and interestingly, the average does not lie in the middle of the interval, either. This is weird.
* Someone complained about a similar thing on RC1 a while ago, and I know for sure that I could not reproduce any such behaviour on RC1 (tested that at that time).
* The same configuration only uses 20-25% while the mouse moves over the project manager.
* The messages notebook is similar to the project manager.
* CPU load is roughly proportional to the number of plugins, even plugins that do *nothing* (code completion wizard, Windows XP manifest) add to it
* Debugger and Compiler are the rule-breakers, these affect CPU by far more than any other plugin
* All plugins except Debugger and Compiler: 13-28% (average ~15%)
* Only Debugger and Compiler: 22-50% (average ~45%)b) custom build from CVS, sources are maybe 5-6 days old

* 13-24% (avg ~20%) with all plugins
* 9-20% (avg ~16%) with all plugins except Debugger
* 10-16% (avg ~13%) with all plugins except Compiler
* 3-9% (avg ~6%) with all plugins except Debugger and Compiler
* 3-9% (avg ~6%) with no plugins at all
New working hypothesis:

* RC1-1, in particular the editor component, sends a lot of plugin notifications or UI messages to every plugin.
* HEAD does not do that, or at least not to the same extent.
* The debugger and compiler plugins are CPU hogs for some reason, even when being idle.
* The theory that the latter is related to OnIdle has to be tested next (will do that this afternoon).

thomas:
Could not wait until afternoon, too interesting... :)

Unluckily, the overall result is a bit disappointing, the changes in CPU time are not really significant:

13-24% (average ~20%) all plugins (including debugger and compiler)  original version
9-22% (average ~16%) all plugins (including debugger and compiler)  after removing OnIdle

It appears to be slightly better, but the two intervals overlap quite a bit, so it may well be that the observed difference is due to inaccurate measurement.

The code was changed in the following manner:

--- Code: ---//void CompilerGCC::OnIdle(wxIdleEvent& event)
//{
//    if (m_Process && ((PipedProcess*)m_Process)->HasInput())
// event.RequestMore();
// else
// event.Skip();
//}

void CompilerGCC::OnTimer(wxTimerEvent& event)
{
if(m_Process)
while (((PipedProcess*)m_Process)->HasInput())
;
}

--- End code ---
(the respective declarations and event table entries were deleted)

These changes were done for CompilerGCC, DebuggerGDB, and PipedProcess, which internally all use this strategy. Another possible optimization would be to move the while into PipedProcess::HasInput, so the two TextInputStreams are not opened and closed for every single line of output read, but that will only affect performance while a compile is running, it should make no difference when idle (probably not an issue, so best leave as is).
Also, I deleted the OnIdle function from ProjectManager because all it did was call Skip() - this is quite useless, we get the same result if we don't insert that function into the event table in the first place.

wxScintilla does some very peculiar idle processing, too. Apparently, the line wrapping is done by calling RequestMore() for each line (?). Using RequestMore in a loop is titled as "not usually a good idea" on comp.soft-sys.wxwindows, hmm... anyway. I removed this idle code to check what difference it makes, but since my test setting has no document open, the event table entry is not generated anyway, so of course there was no difference at all (it might while editing, maybe... but nobody complained so far?).

NotifyPlugins is not guilty of taking up CPU time. I removed each and every call to NotifyPlugins and did not see any difference in CPU load at all.

To summarise:
It is not OnIdle (it could be accused of maybe 5% CPU).
It is not NotifyPlugins (not noticeable at all).
Neither compiler nor debugger spawn threads secretly.
Whatever eats those 15% of CPU time, must consquently be related to UI events.

Or... any other ideas?

thomas:
I have to revoke the above post. The difference is significant. Very much, you could say.

My previous "measurement" was this:
- open Taskmanager, go to process list
- perform some action (move mouse etc.) for about a minute
- remember the highest and lowest CPU load during that time
- remember what appears to be "the mean" load
- write that down

As the perceived difference was not too big and the "measurement" was obviously subjective, there could very well have been a Type II Error. Therefore, I planned some more "scientific" measurement:
- open Taskmanager, go to CPU usage chart
- set Refresh frequency to lowest, so peak artefacts are averaged out by Taskmanger
- perform some action
- take a screenshot
- compute the area under the curve over a unit interval
- compare AUCs

Looking at the resulting graphs, it is obvious that calculating the AUC is not necessary at all:


Peaks in order of their appearance: application startup, moving mouse over empty editor area, opening document, moving mouse over editor, typing and scrolling, application shutdown.

This result is particularly stunning not only because of the clear difference shown, but also by the fact how much perception and objective data can deviate.

The correct conclusion must therefore be: Removing OnIdle() reduces CPU time by about one half.

rickg22:
The ProjectManager's OnIdle was added for future expansions. In any case, please submit the patches for the plugins so we can get them fixed :)

Just something that catches my attention. Why does the plugin's OnIdle just check HasInput() and not doing anything to retrieve such input? Is it just discarding the data?

zieQ:
Humm, interesting...

But did you try benchmarking the code with a profiler? This would be objective measurements instead of your subjectives ones. I remember that the windows task manager is not accurate for anything except for detecting the most resource consuming process ;) You can try LTProf (the demo version, not free !) which do not instrument the code. On my computer, the most consuming part is the wx event loop dispatch (see call stack)



[attachment deleted by admin]

Navigation

[0] Message Index

[#] Next page

[*] Previous page