[mythtv-users] 0.26 beta -- Build background buttonlist

[Jim Stichnoth]

On Tue, Aug 7, 2012 at 3:45 PM, Evuraan <evuraan at gmail.com> wrote:
> /sic/
> [825182e] Speed up loading of the Watch Recordings screen and the
> Previously Recorded screen by doing most of the buttonlist
> initialization in the background. The speedup is most noticeable when
> the screen contains hundreds or thousands of entries and mythfrontend
> is running on a relatively slow processor such as an Atom.
> /sic/
>
>
> 2012-08-07 13:22:20.526353 I  Build background buttonlist item 0
> 2012-08-07 13:22:22.085708 I  Build background buttonlist item 100
> 2012-08-07 13:22:24.810141 I  Build background buttonlist item 200
> 2012-08-07 13:22:26.834581 I  Build background buttonlist item 300
>
> Watch Recordings screen on my front-end still feels way too slow; just
> a tiny,tiny bit  better than 0.25.
>
> I run 0.26.0~master.20120508.0d8e93c-0ubuntu0mythbuntu1 btw,
>
> //Or I am so spoiled by xbmc's menu response.

Entering the Watch Recordings screen requires several steps:

1. Load and parse the recordings-ui.xml theme file.
2. Load and cache the ProgramInfo objects from the backend.
3. Translate cached ProgramInfo objects into MythUIButtonListItem objects.
4. Compute layout and draw the screen.

The speedup here is only in the third step.  From each listing, we
have to generate 68 (at last count) strings for the theme to
potentially use.  A number of these strings involve date calculations
and are therefore relatively expensive to compute.  Multiply by many
hundreds or thousands of listings, and you can end up with quite a
number of cycles.  The performance improvement comes from deferring
almost all of the work in the third step until the screen is first
loaded, then finishing up in the background.

The log messages are there to let you know why the frontend CPU is
running at 100% even though it appears the screen is fully drawn and
nothing is going on.

If you're still seeing a long delay between selecting Watch Recordings
and the screen being drawn, it's most likely another issue, like a
slow backend in the second step.

BTW, on my lowly ION system, the time spent per 100 elements in the
background seems to be about half what yours is showing.  What
hardware are you using?  Is it a standalone frontend, or is something
else running there?

Jim