[mythtv-users] Mythfrontend idle cpu consumption help
stichnot at gmail.com
Fri Jan 22 23:52:15 UTC 2010
On Fri, Jan 22, 2010 at 2:11 PM, jansenj <jansenj+myth at gmail.com> wrote:
> On Thu, Oct 29, 2009 at 3:04 PM, jansenj <jansenj+myth at gmail.com> wrote:
>> I just noticed that when I do a "top" that mythfrontend.real is consuming
>> almost 15% CPU when it is running at 1Ghz. I'm using mythbuntu theme with
>> Qt on mythbuntu's 0.22-fixes packages. Any ideas what could have changed?
>> Or is it something I could have changed?
> I thought I'd reply to my original post.
> The behavior here is without a doubt attributed to mythui pulse.
> It looks like animate is called at 70Hz, and as it was said in this thread,
> this can be dropped much lower if you don't have animations, but it takes
> modifying source and rebuilding.
> I'm astounded that the majority of the people reporting this behavior report
> similar cpu usage levels, no mater what the clock speed of the cpu. In fact
> I can have mine clocked at 1Ghz or 2Ghz, and both result in a 14%
> utilization, so there seems to be an odd timing or wait component that
> doesn't give up context, but I couldn't find one. But if we do the math,
> every time animate runs, it consumes the cpu for a full 2ms.
> It looks like Animate calls a bunch of pulses from all sorts of object
> types: clocks, images, text...etc. It looks like to me, that all pulses
> eventually end up calling mythuitype::pulse which sets up the screen to
> redraw if it detected any motion or alpha blending changes. Then it loops
> through and does a pulse on all the given children for that single item.
> Something that confused me: I tried commenting out all the pulse bodies that
> call mythuitype::pulse, and I still could get into a mode where 14%
> utilization was seen. But if I comment out the body of mythuitype::pulse
> the cpu usage drops way down, but myth doesn't work very well if you do
> that. After all, it looks like for every iteration of animate
> mythuitype::pulse gets called 39 times in my setup. That means, normally,
> it is doing an alpha pulse and motion pulse 2700 times per second each. But
> I wouldn't think that would add up to 140ms of time.
Here's something I just discovered. Try adding "usleep(500);" as the
first line of the MythMainWindow::animate() method, and see what
happens to your idle CPU usage. Also try various values between say
100 and 1900. You should find some sweet spot where your CPU usage
drops below 1%.
Another thing to try is to change animate() so that it returns
immediately without doing anything (and you have to tolerate the fact
that the screen never updates). You should still find your CPU usage
at 14% (or 7% in my case). This indicates that neither animate() nor
anything it calls is the culprit.
I think the problem here is the QTimer class. It apparently tries
very hard to make the timer fire off at the precise interval with
perhaps near-microsecond accuracy. It would appear that it does an OS
sleep for most of the interval and then does a CPU-consuming busy-wait
for the last part. That last part appears to be almost 1ms
busy-waiting for the 7% crowd and almost 2ms for the 15% crowd.
Whether it's 1ms or 2ms probably depends on the version of the Qt
library and/or the kernel config options.
We probably don't need this level of timing precision in MythUI. One
possibility is to replace the use of QTimer for invoking animate()
with some less precise timer that doesn't busy-wait. Another
possibility is to somehow tie this in to the video sync.
More information about the mythtv-users