User forums > Using Code::Blocks

High CPU usage

<< < (7/11) > >>

thomas:
Call it a misnomer. HasInput() indeed polls input and posts messages to the attached event handler. As a side effect, it also returns true when it had input :)

Patches, humm... ok, but I'd better checkout a pristine copy first, after I went through the code like a berserker.  :lol:

So... I'll change CompilerGCC, DebuggerGDB, and PipedProcess to avoid using OnIdle, but leave the
ProjectManager::OnIdle function in place and only comment the event table macro .

To wxScintilla, I will only add a "NOTE" comment, as you cannot just modify the idle function there without affecting line breaking. Maybe someone wants to look into that another time, but for the time being, this is probably not so much of an issue. The "typing" peak of the graph looks intimidating, but I was really hitting keys as fast as I could. If someone really experiences the fan winding up due to typing, one can still look at that.

thomas:

--- Quote from: zieQ on September 14, 2005, 04:45:43 pm ---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 ;)

--- End quote ---
I did not profile the code, unluckily. Ow... rebuild everything with profiling info? Painful :( But I might still do that later.
I guess the graphs are telling enough, though. Using lowest update speed, task manager averages total cpu usages for about 4-5 seconds per tick, given that nothing else ran on this machine, that should give a quite comparable measure. Hopefully, we may assume that the Windows scheduler knows how much time it has spent in user code. The peaks are on a consistent level for > 30 seconds every time, too, so as a general comparison (without knowing the actual function) I guess it will do.


--- Quote from: zieQ on September 14, 2005, 04:45:43 pm ---On my computer, the most consuming part is the wx event loop dispatch (see call stack)
--- End quote ---
That, too, confirms my hypothesis. The exact thing I am trying to do by removing OnIdle and WakeupIdle (and RequestMore) is reduce the number of messages that get fed into the message queue.

rickg22:
Hmmmmmmmmm if this is the case (posting messages), what are the chances of reentrancy in the code? Shouldn't we add some kind of flag to prevent reentrancy in the timer function? i.e. if the message polling takes too long, the ontimer would get triggered again, leading to crashes etc etc.

thomas:
For all I know wxWindows takes care of that, so we need not fear that.
But it is nevertheless inefficient to send that many messages.
To give an example, wxScintilla has code like this:

--- Code: ---void wxScintilla::OnIdle (wxIdleEvent& evt)
{
m_swx->DoOnIdle (evt);
}
...
void ScintillaWX::DoOnIdle(wxIdleEvent& evt)
{
if ( Idle() )
    evt.RequestMore();
else
    SetIdle(false);
}
...
bool Editor::Idle()
{
bool wrappingDone = (wrapState == eWrapNone) || (!backgroundWrapEnabled);
...
return !idleDone;
}

--- End code ---

In other words, this code does "post idle messages as long as there is text left to wrap" and "do the actual work when the messages come back in".
It is not surprising that the profiler shows the event loop dispatcher as the most CPU intensive section. It's being used :)

rickg22:
Yes, it might sound inefficient, but take into account that each idle cycle is handle separately.

In other words, if you have 500 objects doing idle processing, each one gets its own timeslice. You could call it "cooperative multithreading".

I think this idle handling of scintilla is precisely what makes it so responsive. (Believe me, I've used other editors, and word wrapping a 300K file can be QUITE unresponsive! )

Navigation

[0] Message Index

[#] Next page

[*] Previous page