Code::Blocks

User forums => Using Code::Blocks => Topic started by: phear on June 16, 2005, 07:16:47 pm

Title: High CPU usage
Post by: phear on June 16, 2005, 07:16:47 pm
Codeblocks has an idle cpu usage of 10-12%, which seems way to high.

My specs are:

Windows XP SP2 Pro, fairly well tweaked.
Pentium M 1,8GHz
1024MB RAM

Am I the only one (or selected few) who suffers from this? And what may cause this?
Title: High CPU usage
Post by: Profic on June 16, 2005, 07:28:58 pm
WinXP SP2 Pro, tweaked too
Pentium-4 2.8/256MB RAM
and c::b (with one project within ~100 files loaded) in idle state consume nothing
I have system idle cpu utilisation ~1.5%, and most of it is system monitoring software (~1.25%) and other player (~0.25%)
Title: High CPU usage
Post by: Anonymous on June 16, 2005, 07:32:15 pm
it sounds like it could be the codecompletion plugin playing tricks on you - have you tried disabling it?
Title: High CPU usage
Post by: rickg22 on June 16, 2005, 07:34:22 pm
Try enabling the cache on codecompletion. The parser keeps running on the background until all files are read.
Title: High CPU usage
Post by: phear on June 16, 2005, 08:52:34 pm
It actually didn't seem like codecompletion was much to blame. After some trial and error, I've found that the compiler plugin uses about half, and it seems the GDB plugin alongside the compiler plugin stands for some.

The CPU usage oscillates quite a bit more, but I will give it some time, and see if it stabilizes.
Title: High CPU usage
Post by: rickg22 on June 16, 2005, 09:17:46 pm
you're constantly debugging and setpping into your app, right?
Title: High CPU usage
Post by: Anonymous on June 16, 2005, 09:30:44 pm
no... not debugging at all.
Title: High CPU usage
Post by: Anonymous on June 16, 2005, 09:43:00 pm
ok, I've done some more testing, this time altering code, compiling and debugging, and then letting it idle for 5-10 minutes. The results are as follows:

no plugins: 0-1%
compiler + gdb: 3-5%
compiler + gdb + code completion w/caching: 3-6%
compiler + gdb + code completion wo/caching: 4-8%
all plugins: 7-10%

I've also found that simply moving the mouse over codeblocks, raises cpu usage to 20-70% depending on mouse speed. This is regardless of whether codeblocks has focus or not.
Title: High CPU usage
Post by: rickg22 on June 16, 2005, 10:59:26 pm
hmmmmmmm interesting. Hadn't noticed. I guess this is part of the events management (wxWidgets).
Title: High CPU usage
Post by: thomas on June 17, 2005, 05:33:57 pm
Hmm... cannot confirm that observation.

System: Athlon64 3400 / 1G / WinXP SP2 /c::b 1.0finalbeta

2 Projects loaded, 6 files open, all plugins loaded, no Debugger, idle:
Total CPU 2%,
taskmgr.exe 1%    <--- that's where my cpu goes :)
svchost.exe 1%     <---
codeblocks.exe  0%

same, but moving Mouse up and down over project manager:
codeblocks.exe 18%   (quite clear why that has to be)

frenzily moving Mouse over editor window:
codeblocks.exe 24%   (quite clear, too)

compiling project:
cc1.exe 99%  (well, duh :-)  )

debugging app that is blocking in a syscall (getchar):
codeblocks.exe 0%
app.exe 0%

debugging app that runs in a tight infinite loop with a watch:
codeblocks.exe 5%
app.exe 95%

This looks quite normal to me, does it not?

EDIT:
Forgot about the "moving mouse thing":
Moving the mouse fires a lot of events and requires calculations like "do tooltips have to be popped up?" and "do I need to change a button's outline?" or "is some plugin maybe involved?", so quite clearly this takes cpu.
I can get Windows Explorer to use 3-4% cpu by moving the mouse, too, and Explorer does quite a lot less than an IDE.
Title: High CPU usage
Post by: Anonymous on June 18, 2005, 01:11:01 pm
Seems like I've got it pretty bad then. I can't explain it, so it looks like it might be a dealbraker for me (being on a laptop, it's pretty annoying when the fan is constantly  on and revving up and down).

As far as the mousemoving thing goes, there should be no checking for tooltips (or anything else for that matter), as tooltips display on delay, so it's just setting a delay, which certainly shouldn't use 70%. I can't even get a tooltip at all in the editor actually. There's nothing else mousemove related there either. The only thing that appears to happen when moving the mouse is hittesting, which should be pretty non-exhaustive, unless there are some future features having a lot of logic implemented there.

As far as wxWidgets go, I have a hard time believing a library in so wide-use has this issue. It might be however, that the API is prone to be used in such a way.
Title: High CPU usage
Post by: Anonymous on June 23, 2005, 02:11:20 pm
Quote from: Anonymous
As far as wxWidgets go, I have a hard time believing a library in so wide-use has this issue. It might be however, that the API is prone to be used in such a way.

Hmm... sadly, wxWidgets has quite a few issues. I am struggling with some of them at the present time. And yes, a few things are quite inefficient.

But despite the many reasons to hate wxWidgets, it has one advantage, which cannot be denied... It may never work perfectly, but it kind of works somehow, and it does so on several Platforms without requiring you to change a line of code (well, almost).

And you have to account for the fact that code::blocks as a beta version is still an awful lot
- faster (about 2-3 times in some things?)
- more stable (c::b crashes total: 0  / dev-cpp crashes per day: 4-6)
- smaller
- better usable
than for example Dev-CPP in version 4 or 5.

So, despite all evil that comes with wxWidgets, it still enables people to produce quite good end results.


Is this fan on/off issue not something that can be configured under power management? Surely, it can be configured to something like "When on AC, always run CPU at full speed"?

Another way to keep the fan running is this, of course:

Code: [Select]
int main()
{
SetThreadPriority(GetCurrentThread(), THREAD_PRIORITY_LOWEST);
for(;;)
;
}


That will prevent the fan from ever going off and the only thing that you lose is the validity of CPU idle time in the task manager ;)
Title: High CPU usage
Post by: rickg22 on June 23, 2005, 05:39:23 pm
Good idea. Submit a patch for it then :)
Title: Re: High CPU usage
Post by: Birdeeoh on September 13, 2005, 02:42:03 am
I'd just like to jump in with my take -
With a fresh install of 1.0rc1, my cpu usage while moving the mouse or typing into the editor is 25-30%.  XP Pro has a really weird time reporting CPU usage for duel processors (I have P4 w/HT) and one "CPU" at full reports back 50% overall usage.  So 25-30 is likely an understatement.

Disabling all of the plugins, and mouse/typing only causes 5-6% usage.  Add the GDB plugin adds 4% more usage, and adding the compiler plugin adds 10% more - the others seem to add only a little.

As an anonymou poster pointed out in this thread, it's a potential dealbreaker for quite a few people - I, too, am on a laptop and the sporatic foray into 10% + usage territory causes the fan to rev all over the place.

Someone suggested the overhead is from wxwidgets and, while that MAY be the case from suboptimal usage of wxw I'd have to say it's not near definite.  My previous IDE, Chinook, was also built with wxwidgets and the typing/mousing over the window will never get the CPU above 2% - typical for ANY application.

Codeblocks looks so great and full featured and, again unlike Chinook, it's actively developed by a community and seems to have support for some time to come.

But I'd sure like to be able to use fancier plugins without biting into my CPU hard enough to cause the fan to ramp up.  Normally I only ever hear the fan speed up while I'm gaming  :)

Anywho, on a more general note, it looks great overall and keep up the great work!
Title: Re: High CPU usage
Post by: rickg22 on September 13, 2005, 04:43:36 am
Hmmmmmmmmmmmmmmmmmmmm

This makes me think. What events in the compiler / debugger / (code completion?) plugins are affected by mouse moves?
Title: Re: High CPU usage
Post by: thomas on September 13, 2005, 11:07:23 am
This maybe?

Code: [Select]
EVT_IDLE( CompilerGCC::OnIdle )
EVT_IDLE( DebuggerGDB::OnIdle )

These plugins read stdout from processes they launch on a regular base triggered by a wxTimer (100ms). OnTimer() does not do anything except for calling wxWakeUpIdle(), and OnIdle() does the actual polling.

While moving the mouse, the system goes idle quite a few times, so it may be that OnIdle() is indeed called many, many times per second. At the very least, this means a lot of calls to wxProcess::IsInputAvailable() which calls wxStream::CanRead(). If there are actually processes running, two wxTextInputStreams  are opened in addition, and one line is read from each.

I am not saying this *is* the actual cause, but it might just be. One should run gprof to see how often OnIdle() is really called. If it is 50 or 100 times per second, we have a culprit. In that case, have OnTimer() poll for input, which is better anyway, and remove OnIdle().
Even if it is not that, gprof will likely find some function that gets called amazingly often, providing a starting point for the search.
Title: Re: High CPU usage
Post by: Michael on September 13, 2005, 11:53:10 am
Hello,

I have remarked the "same" high CPU usage with my configuration:

CodeBlocks 1.0-RC1-1 (all plugins + cache activated)
Windows XP Pro SP2
Pentium M 1,8 GHz
1024 MB RAM

Simply moving the mouse cursor on the CB window, the CPU usage rises around 20-30%, sometimes until more than 40%, other time around 10-20%.

Ad-Aware SE Personal rises the CPU usage until 11% and Windows Media Player until 10% approximately (just moving the mouse cursor at different speed and in/out the application window).

Therefore, CB increases the CPU usage around 2-4 times more (to confirm this result, it would be necessary to perform more comparisons and tests).

Anyway, I have not experienced particular problems using it and all seems to work well.

Best wishes,
Michael
Title: Re: High CPU usage
Post by: rickg22 on September 13, 2005, 04:50:45 pm
OnIdle is safe to use... it's called only once per event cycle. In fact, it does what its name says: It's only activated when the system is IDLE.

But I'm not sure if the wakeupidle should be used...

In that case, I think OnIdle should use a counter or an internal timer to assure a MAXIMUM of calls per second.

Instead, if you use a timer instead of idle, you specify the EXACT number of times the routine will be called.
Title: Re: High CPU usage
Post by: thomas on September 13, 2005, 05:53:55 pm
The point I am having about OnIdle is that if you move your mouse, the OS generates a message, wakes up some thread to move the pointer, does some rectangle hit tests, possibly some MouseOver or MouseEnter/Leave messages are fired and processed, which alltogether goes rather quick (few dozen microseconds?), and then the system *goes idle* again.
If you move your mouse over a window and dump all WM_MOUSEMOVE notifications to a console, you get an idea about how many messages Windows(R) creates... 30-50 per second is not unusual. That means that you call OnIdle quite a few times per second (unless wxWindows filters these).

That might indeed possibly be an issue. First, message queues are usually thread-safe (I don't actually know about wxWindows, but I strongly assume they are!), so handling 50 messages means acquiring and releasing 50 mutexes or semaphores (or locked atomic writes, whatever) as a basic overhead. This is particularly bad on a system with NUM_CPU > 1.
And second, while that may still not be an awful lot, there are still several library calls (IsInputAvailable, CanRead, ...) and allocations/deallocations of complex objects (wxTextInputStream, wxEvent), which are not free. All of these derive from wxObject, they run non-trivial constructors and have a chain of virtual destructors. This is not noticeable if you create a few objects once, but if you allocate/destroy a couple of them several dozen of times every second, it adds up, so the resulting payload is not necessarily trivial.
At the very least, it is worth looking at.

WakeupIdle, like the docs say, forces idle events to be fired, even if the system is idle already. However, this function is only called twice every 100 ms, and only while either a compile or the debugger is running, too, so that should not do much harm. Still, polling for input directly inside OnTimer would be more efficient. That would remove the necessity to have OnIdle at all, and it would remove posting and handling of one message per timer event, as well as the creation/destruction of half a dozen objects each time.
I believe that calling WakeupIdle is necessary with the current design, because otherwise you could not run the compiler and debugger plugin at the same time. Whichever comes first would steal the idle events from the respective other (unless explicitely calling Skip), and the other would never poll for input.
Title: Re: High CPU usage
Post by: rickg22 on September 13, 2005, 07:32:28 pm
Is there a way to check the ellapsed time in milliseconds since the last idle event handled?

Also, something makes me think. Is there a point on doing these checks if NO compilation or debug session has been started yet? I think we need a couple of if's  in there.

Hmmm....

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

void CompilerGCC::OnTimer(wxTimerEvent& event)
{
wxWakeUpIdle();
}

I think we should add an "if(m_Process)" before doing the wxWakeUpIdle, this would save us from creating an idle events chain. The same code applies for debuggergdb.
Title: Re: High CPU usage
Post by: thomas on September 13, 2005, 07:53:26 pm
Or better, you could simply copy the first line from OnIdle into OnTimer, and delete OnIdle alltogether.
That should work the same (I am pretty sure it does because I poll stdout from inside OnTimer in the svn plugin, too - it works fine).

If my theory is correct, you have solved the problem with this.

If my theory is not correct, you don't lose anything - the only difference is that the system has to push one less message through its queue and you save a few calls.
Title: Re: High CPU usage
Post by: rickg22 on September 13, 2005, 09:07:33 pm
Why don't you change the code and try it out?
Title: Re: High CPU usage
Post by: grv575 on September 14, 2005, 05:03:37 am
Maybe profile the debugger polling as well?  It takes quite a long time to step through a program as is (time between pressing the step/step over button and the actual update is very unresponsive...).  I'm thinking the way the gdb output is polled and read could be optimized to make this more instantaneous.
Title: Re: High CPU usage
Post by: rickg22 on September 14, 2005, 05:16:40 am
HMmmmmmmmmmmmmmmmmmmmmmmmmm

Did you try modifying the code and moving the mouse around?
Title: Re: High CPU usage
Post by: grv575 on September 14, 2005, 09:48:44 am
No I've just looked at the code so far.  Haven't tried changing delays or logging events or anything yet.
Title: Re: High CPU usage
Post by: thomas on September 14, 2005, 10:55:24 am
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
b) custom build from CVS, sources are maybe 5-6 days old

New working hypothesis:
Title: Re: High CPU usage
Post by: thomas on September 14, 2005, 12:57:30 pm
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: [Select]
//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())
;
}
(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?
Title: Re: High CPU usage
Post by: thomas on September 14, 2005, 02:56:52 pm
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:

(http://img219.imageshack.us/img219/571/timings8wk.png)
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.
Title: Re: High CPU usage
Post by: rickg22 on September 14, 2005, 04:35:48 pm
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?
Title: Re: High CPU usage
Post by: 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 ;) 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]
Title: Re: High CPU usage
Post by: thomas on September 14, 2005, 05:01:42 pm
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.
Title: Re: High CPU usage
Post by: thomas on September 14, 2005, 05:27:57 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 ;)
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.

On my computer, the most consuming part is the wx event loop dispatch (see call stack)
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.
Title: Re: High CPU usage
Post by: rickg22 on September 14, 2005, 05:39:33 pm
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.
Title: Re: High CPU usage
Post by: thomas on September 14, 2005, 06:05:56 pm
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: [Select]
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;
}

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 :)
Title: Re: High CPU usage
Post by: rickg22 on September 14, 2005, 08:09:27 pm
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! )
Title: Re: High CPU usage
Post by: thomas on September 14, 2005, 08:18:48 pm
And luckily, Scintilla does not need to word wrap all the time, too. That's why I said the Scintilla bit is probably not an issue (unless some complains about the fan winding up when he presses keys).

Anyway, for the compiler, it seems to make sense, there is no noticeable difference when compiling a file, just the overall load is lower.
Title: Re: High CPU usage
Post by: takeshi miya on September 14, 2005, 09:51:18 pm
thomas: if you don't want to profile, I recommend you the freeware Sysinternal Process Explorer, it's like the Task Manager, but you can set the refresh time, you can see the CPU/MEM graphs per process, can see the stack or CPU for each thread, support multiple CPUs, etc.

I'm using it as a Task Manager replace.  :)

http://www.sysinternals.com/Utilities/ProcessExplorer.html
Title: Re: High CPU usage
Post by: thomas on September 15, 2005, 12:26:02 am
This is great, thanks :)

I would love to profile all of my code, it is just so painful, especially since gprof is the only profiler I have on my hard drive :s  (I shall look into that LTProf during the weekend).

Can't someone write a one-click profiler plugin for Code::Blocks so my life is not that miserable? :lol:
Title: Re: High CPU usage
Post by: Ceniza on September 15, 2005, 01:26:12 am
Quote from: thomas
Can't someone write a one-click profiler plugin for Code::Blocks so my life is not that miserable?

What about the one being developed? link (http://forums.codeblocks.org/index.php/topic,850.0.html)

I haven't tested it yet but if it's already usable and compiles without problems with Code::Blocks CVS I could provide it in the binary snapshots :)
Title: Re: High CPU usage
Post by: mandrav on September 15, 2005, 09:25:21 am
Hi Thomas et al :)
I just wanted to say why the compiler's and debugger's input polling uses OnIdle().

If we remove the Has Input() from OnIdle() and move it to OnTimer(), everything might work fine for you but it breaks the non-windows builds (at least it used too). In non-windows platforms, any deviation from the current strategy, will lock the process being checked for input (and subsequently C::B). If I remember correctly from the tests I had performed back then to see what was wrong, it looked like the stream wouldn't correctly return eof...
If someone wishes to debug this, be my guest :P
The current way things are done, is the only way I could find to correctly launch a process and read its input/output without freezing.

Maybe by simply changing OnTimer() to check for valid process before calling wxWakeUpIdle(), could satisfy all sides...
Title: Re: High CPU usage
Post by: zieQ on September 15, 2005, 11:31:52 am
thomas, with LTProf, you don't need to recompile the code, that's why I'm happy with it ;)

Also note that, on my screenshot, the idle event processing is at the second place ;)
Title: Re: High CPU usage
Post by: thomas on September 15, 2005, 03:46:14 pm
lock the process being checked for input (and subsequently C::B).
I did experience that problem with the svn/cvs plugin in very early versions. As an "optimization", I only polled output once in OnTerminate. That way, you would get all output in one chunk, but that was fine.
The nasty thing about this approach is that it works perfectly for output less than the pipe size (4k). However, when the invoked program outputs more than 4k, the pipe will block, and you wonder why suddenly everything freezes. Checking out Code::Blocks suddenly froze my PC  (by coincidence, as the project grew bigger, cvs output just crossed the 4k border) when all was fine the day before.
With regular polling via OnTimer, I haven't experienced a similar problem yet.

If I remember correctly [...] stream wouldn't correctly return eof...
Oh yes, had that too, that's when you don't poll in OnTerminate. When polling via OnTimer, I thought "why poll again in OnTerminate then!". OnIdle 99.9% certainly polled just before the process dies, but OnTimer only polls on fixed time intervals. After OnTerminate, m_process is null, so EOF is not correct.
PipedProcess does clean up in OnTerminate, so it should actually work. Did you actually have such a problem recently, or are these only the heirs of long forgotten nightmares from the dark ages?

Maybe by simply changing OnTimer() to check for valid process before calling wxWakeUpIdle(), could satisfy all sides...
Sounds like a good compromise. That will eliminate idle messages as long as no compile is running. While a compile is running, CPU usage is ~99% anyway, so the cpu fan will spin up either way ;)


What about the one being developed?
:oops: Was completely unaware of that.
Title: Re: High CPU usage
Post by: rickg22 on September 15, 2005, 05:23:06 pm
Cool! So all we need (read: we = Yiannis :lol: ) is to add OnTerminate stuff and we'll get rid of the Idle stuff? :)
Title: Re: High CPU usage
Post by: thomas on September 15, 2005, 07:41:38 pm
No, don't need to add anything, OnTerminate is already good the way it is. It always was.

But like I pointed out, polling inside OnTerminate alone is not enough, that could lead to filling the pipe until it blocks in some scenarios ( >4k of compiler warnings).
The reason OnTimer (and possibly OnIdle) is needed is that you want to poll before that happens.

I strongly believe that OnIdle is unnecessary when polling is done both in OnTimer and OnTerminate, though (which is done). The former prevents the pipe from overfilling, and the latter catches the last few lines of output that would otherwise slip through. Adding OnIdle on top of that only polls a few times more, but should not make a difference really.
Title: Re: High CPU usage
Post by: grv575 on September 15, 2005, 11:46:15 pm
Sound like the right way to go about it (OnIdle + OnTerminate).  I'd be willing to test on windows and linux (wx2.4.2 & wx2.6.1 which are already built for both platforms) to make sure it doesn't freeze up.
Title: Re: High CPU usage
Post by: thomas on September 15, 2005, 11:52:55 pm
Sound like the right way to go about it (OnIdle + OnTerminate).
OnTimer + OnTerminate? Else, we can leave it as it was before. :)
Title: Re: High CPU usage
Post by: grv575 on September 16, 2005, 05:19:55 am
Heh.  yes that's what I meant.
Title: Re: High CPU usage
Post by: thomas on November 22, 2007, 03:07:15 pm
Coming back to the old topic of high CPU consumption (hopefully I picked the right thread):
I just found something that I wasn't sure what it is needed for, commented it out, and surprisingly found my old suspicions about update events confirmed.

(http://img518.imageshack.us/img518/8459/cpuhc4.png)

This image shows
(1) typing legible text at my normal typing speed
(2) typing illegible text like aflkdjflfkdjfalsdfsdafs at a significantly higher speed
(3) permanently holding down the right arrow key
(4) changing text selection using the mouse

The upper half of the image is Code::Blocks HEAD, the lower half is Code::Blocks HEAD with lines 720-722 in sdk/editormanager.cpp sdk/cbeditor.cpp commented out. The graph needs no further explanation, I think.

Now, it would be interesting to see if this can fix the "100% CPU" problem and the "cpu fan spinning up on my notebook when I type" problem for the people affected.
Title: Re: High CPU usage
Post by: dmoore on November 22, 2007, 03:22:41 pm
nice! I suspect this may also help those linux users experiencing editor slowness issues...
Title: Re: High CPU usage
Post by: artoj on November 22, 2007, 03:29:46 pm
Great! I'll test this on my laptop.
Title: Re: High CPU usage
Post by: mandrav on November 22, 2007, 03:31:51 pm
Real performance killer has been identified and committed in rev4660.
Please test and report back :).
Title: Re: High CPU usage
Post by: artoj on November 22, 2007, 04:13:57 pm
Revision 4660
Ubuntu Feisty
wxGTK 2.8.6

Pentium M 1.73GHz (single core)

Test results (CPU usage from "top" command):

    typing normal text at normal speed: 10 %
    typing random text: 17 %
    permanently holding the down key: 56 %
    changing selection with mouse: 50 %

EDIT: These are the results (http://forums.codeblocks.org/index.php/topic,4504.msg35633.html#msg35633) that I got (almost) exactly year ago.

EDIT: And test results using Thomas' patch w/ earlier revision than 4660:

    typing normal text at normal speed: 7 %
    typing random text: 12%
    permanently holding the down key: 60%
    changing selection with mouse: 50%

These are not the average but the highest I got. I don't know if these test results make any sense. Interesting thing is that that when I now look at the "top" program I can see Code::Blocks consuming around 2 % of the CPU all the time even when I'm not using that machine.
Title: Re: High CPU usage
Post by: Abscissa on May 30, 2008, 12:29:27 am
I'm having a problem with high CPU usage too, on the latest version:

CPU/Mem usages when the porgram has a simple project loaded, is doing nothing, and has been doing nothing for a few minutes:

CodeBlocks v8.02: 18%-22%, ~5MB

For comparison:
Visual C# Express 2008: 0%-1%, ~80MB
Eclipse v3.3.2: 0%-1%, ~100MB
Flash MX Pro 2004: 0%-1%, ~42MB
Firefox v2.0.0.13: 0%-1%, ~50MB

My Machine:
WinXP Pro SP2
Celeron 1.7GHz
1GB RAM
Title: Re: High CPU usage
Post by: MortenMacFly on June 02, 2008, 09:56:33 am
I'm having a problem with high CPU usage too, on the latest version:
You could try by starting to deactivate (contrib...) plugins. Probably you have a plugin installed that takes a lot of CPU usage for some obscure reason. I'd say for the most of us (including me) C::B takes nearly no CPU power.
Title: Re: High CPU usage
Post by: Abscissa on June 07, 2008, 11:25:20 pm
I'm having a problem with high CPU usage too, on the latest version:
You could try by starting to deactivate (contrib...) plugins. Probably you have a plugin installed that takes a lot of CPU usage for some obscure reason. I'd say for the most of us (including me) C::B takes nearly no CPU power.

I haven't installed any plugins that didn't come with codeblocks (although I did choose the "Full" install, as I always do). I tested them all and it doesn't look like there is any single plugin that's causing the problem. Rather, the effect seems to be cumulative, with a few of them weighted more havily than the others. Here are my testing results:

In all tests, IDE had a project loaded but was idle and mouse was not moving (except where otherwise noted).

All plugins disabled: 0%-2% (Never spikes above 2%)
All plugins disabled, moving mouse around: 6%-16%

One Plugin Only:
(Note, these are ALL the pluging I have installed, and all of them came pre-installed and pre-enabled with codeblocks v8.02)

Debugger: 1%-5%
Code Completion: 0%-4%
Compiler: 0%-4%

ThreadSearch: 0%-3%, spikes at 4%
DragScroll: 0%-3%
Keyboard Shortcuts: 0%-3%
AutoVersioning: 0%-3%
BrowseTracker: 0%-3%
Code Snippets: 0%-3%
Files Extention Handler: 0%-3%

Dev-C++ DevPack updater/installer: 0%-2%, spikes at 4%
Library Finder: 0%-2%, spikes at 4%
Source Exporter: 0%-2%, spikes at 4%

Code Profiler: 0%-2%, spikes at 3%
Foreign Project Importer: 0%-2%, spikes at 3%
Help plugin: 0%-2%, spikes at 3%
Open Files List: 0%-2%, spikes at 3%
ToDo List: 0%-2%, spikes at 3%
wxSmith MIME Plugin: 0%-2%, spikes at 3%

XP Look and Feel: 0%-2%
Source Code Formatter (AStyle): 0%-2%
AutoSave: 0%-2%
BYO Games: 0%-2%
ClassWizard: 0%-2%
Code Statistics: 0%-2%
Copy strings to clipboard: 0%-2%
Environment Variables: 0%-2%
Koders Query: 0%-2%
Regular Expressions Testbed: 0%-2%
Scripted Wizard: 0%-2%
Symbol Table Plugin: 0%-2%
wxSmith: 0%-2%
wxSmith Contrib Items: 0%-2%

All 3 wxSmith Plugins: 0%-2%, spikes at 3%

Five Plugins enabled at once:
Debugger, Code Completion, Compiler, ThreadSearch, and DragScroll: 5%-9%, spikes up to 12%
AutoSave, BYO Games, Code Statistics, ClassWizard, and Koders Query: 0%-3%

Everything except Debugger, Code Completion, Compiler, ThreadSearch, and DragScroll: 3%-7%, spikes down to 1% and up to 9%

Everything: 16%-23%