[mythtv] [Announce] Playback Optimization Patch (was: Playback

[David Abrahams]

"Chris Pinkham" <cpinkham at bc2va.org> writes:

>> The frontend was doing a terribly slow regexp creation/search sequence
>> in TV::GetQueuedChanNum that was soaking 14.6% of the process' CPU
>> cycles.
>
>>      bool HasQueuedChannel(void) const
>> -        { return queuedChanID || !GetQueuedChanNum().isEmpty(); }
>> +        { return queuedChanID || !queuedChanNum.isEmpty(); }
>
>
> Would a more correct check without losing existing functionality
> be something like this?
>
>
> bool HasQueuedChannel(void) const
>     { return queuedChanID || (!queuedChanNum.isEmpty() && !GetQueuedChanNum().isEmpty()); }
>
>
> GetQueuedChanNum() strips off leading zeros, whitespace, etc..  Your patch
> would return true if the QString was non-empty which doesn't maintain
> existing functionality.  

Are you sure?

> With the above mod, we only do the expensive QRegExp/find code if
> the QString actually has something in it to check against.

I thought of doing something like that, but as far as I could tell
from the code it was not going to make any difference, because
HasQueuedChannel is private, and only called to decide whether to
process input.  You can just as well discover later that the
keystrokes in the queued channel don't mean anything and I didn't see
any point in complicating things.

Of course, it's possible that I've misanalyzed something; I didn't
look _too_ deeply into what happens when HasQueuedChannel reports
true.

> Can you try this and see where it lies in the middle.  

Sorry, but I don't think I'm going to be spending more time on this
particular issue.  If I were going to "really do this right" I would
completely encapsulate the queued channel number in a class rather
than storing it in a raw string, in such a way that one could ask
whether it was empty or not without incurring needless overhead.  But
-- no offense intended -- this is someone else's efficiency bug; if my
quick patch is unacceptable then they should be working on fixing it.
Every rebuild of the MythTV frontend costs me about 15 minutes because
I can't figure out how to get the build to succeed withour running the
osx-packager.pl script, which does a great deal more work than is
necessary.

> I assume during most cases where there is no queued input that it
> will be just as fast as yours, but will be more accurate in cases
> where there is queued input.

I'm sure it would be.  I'm just not sure it matters.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com