stichnot at gmail
Mar 16, 2012, 10:15 AM
Post #20 of 21
(1398 views)
Permalink
|
On Fri, Mar 16, 2012 at 5:33 AM, Dan Wilga
<mythtv-users2 [at] dwilga-linux1> wrote:
> On 3/15/12 10:59 AM, Dan Wilga wrote:
> I ran my test on 0.24-fixes (JYA), and 7.5 seconds went down to 5
> seconds. That's with 1353 recordings, on an ION1 330.
>
> Based on my, and others', success, I'd say the patch is RTBC and WTBC
> (Welcome) too.
It's good to know that I wasn't the only one affected by the
performance. Let me try to summarize and set expectations.
Bringing up the Watch Recordings screen involves several steps: (1)
load up the recordings-ui.xml theme file, (2) load and cache
ProgramInfo objects from the backend, (3) generate display strings
from the ProgramInfo objects, and (4) build the screen layout. I
think (1) and (4) are pretty fast. (2) involves the frontend waiting
for data from the backend, which is probably dominated by the sql
query. (3) is all on the frontend, and can take a while because all
possible strings (total of 68 last time I counted) are generated for
every ProgramInfo object in the desired recording group, and a bunch
of those strings are dates and times which can be notoriously
expensive to generate.
The patch works by deferring the work in (3) until it is actually
needed. So instead of waiting to generate 68 strings times 2000 (or
whatever) recordings, it generates 68 strings times 10 items on the
page, or however many items per page the theme specifies, which is of
course far less than 2000. So you pay a tiny performance penalty when
you page through the listings for the first time, but it won't be
noticeable, and the strings are cached so that paging through a second
time has no penalty.
The actual time component of (3) can be best evaluated through the
"Change Group Filter" menu item, which basically only involves step
(3) and not the other steps. (You may have to press MENU twice to see
the Change Group Filter option.)
On a modern and reasonable-performance CPU without the patch,
processing even 2000 recordings shouldn't really tax the CPU, but it
can be very noticeable on an ION-based system. In addition, for
reasons we don't yet fully understand, there's something something odd
about Qt on the Mac OS that makes some date formatting unbelievably
expensive, as Jean-Yves has shown, and the patch happens to benefit
that setup as well.
The patch, as written, isn't necessarily as clean and maintainable as
we'd like; think of it as a proof of concept that minimizes the size
of the patch. As such, don't count on seeing it in 0.25.
Nonetheless, I use the patch on my own production system so I'll
definitely keep it up to date in
http://code.mythtv.org/trac/ticket/10161 for anyone else who wants it.
Jim
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users
|
warpme.vcf
