[mythtv-users] 0.25: this is nice

[Jim Stichnoth]

On Thu, Mar 15, 2012 at 3:17 PM, Michael T. Dean
<mtdean at thirdcontact.com> wrote:
> On 03/15/2012 05:29 PM, Yeechang Lee wrote:
>> Jean-Yves Avenard says:
>>> That patch made an amazing difference.
>>>
>>> on my iMac i7 3.4GHz quad-core, it takes 6.7s to load the recording
>>> screen, 0.9s with the patch
>> Yes, after brief testing I can also report a substantial improvement
>> with the 0.24 version of the patch. A list of ~1500 recordings appears
>> in under three seconds, about one third to one half of the time needed
>> without the patch.
>
> Strange.  On my 0.24-fixes (remote) frontend without the patch, I can
> load ~1900 recordings in well under a second (like it's on screen before
> my finger releases the remote button).  It's fast enough I often use the
> Watch Recordings jump point to go back to the "All Programs" at the top
> of the list rather than scrolling.
>
> Are you guys who have extremely slow load times using some non-default
> options, perhaps?  Or do you have poor-performing MySQL servers or
> something?
>
> Have you tried running optimize_mythdb.pl?
>
> I can't believe it's down to CPU or RAM, since JYA's 3.4GHz Core i7 quad
> is much more powerful than my AMD Athlon II X2 250 (3.0GHz dual-core)
> with 2GB RAM.

This is unlikely to be a DB issue.  The best test of that is to go
into the Watch Recordings screen, then switch in and out of the All
Recording group via the "Change Group Filter" menu.  This operation
reuses cached data from the backend.  On a slow frontend with lots of
recordings, it may take several seconds without the patch but is
virtually instantaneous with the patch.

The performance killer is almost certainly the various QDateTime
calculations in ProgramInfo::ToMap().  Most of these involve calls to
MythDateTimeToString().  For people like Jean-Yves who suffer from
poor performance despite a powerful frontend, my bet is either a poor
implementation of QDateTime on the platform, or that their DB Settings
values of ShortDateFormat, DateFormat, and TimeFormat are pushing the
QDateTime code into some bad-performance region.

Jim