User forums > Using Code::Blocks

High CPU usage

<< < (9/11) > >>

zieQ:
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 ;)

thomas:

--- Quote from: mandrav on September 15, 2005, 09:25:21 am ---lock the process being checked for input (and subsequently C::B).
--- End quote ---
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.


--- Quote from: mandrav on September 15, 2005, 09:25:21 am ---If I remember correctly [...] stream wouldn't correctly return eof...
--- End quote ---
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?


--- Quote from: mandrav on September 15, 2005, 09:25:21 am ---Maybe by simply changing OnTimer() to check for valid process before calling wxWakeUpIdle(), could satisfy all sides...
--- End quote ---
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 ;)



--- Quote from: Ceniza on September 15, 2005, 01:26:12 am ---What about the one being developed?
--- End quote ---
:oops: Was completely unaware of that.

rickg22:
Cool! So all we need (read: we = Yiannis :lol: ) is to add OnTerminate stuff and we'll get rid of the Idle stuff? :)

thomas:
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.

grv575:
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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page