[mythtv] [mythtv-commits] Ticket #3326: Implement multiple recordings per transport

[Stuart Morgan]

On Friday 05 October 2007 17:06:06 Daniel Kristjansson wrote:
> > The 27% improvement is impressive though and looking at the patch, you
> > are probably right in saying that a 3% improvement doesn't make it
> > worthwhile.
>
> My optimization of the scheduler was only to fix a performance
> regression due to input groups.

I was aware of that regression, it was the first thing I noticed when trying 
the multirec branch and which I reported to Janne and Shane in IRC. Since 
you've now brought the scheduling times back down to match those in trunk I 
appreciate that the issue is no longer a top priority.

It was in noticing this problem in multirec that I first started to appreciate 
the affects of scheduling on the UI. The problem had always been there, but 
once it was exaggerated by the regression in multirec I started to give it 
more thought.

> > This might be the time to start thinking about the change which could
> > bring significant speed improvements to scheduling - subqueries. That
> > means dropping support for MySQL 3.3 and moving to MySQL 4.1.
>
> If you have programid's the mysql portion of the scheduling only takes a
> few seconds.

The problem there is that many users outside North America don't have 
programids. They are not provided by many of the listings sources used.

> It's the rest of the scheduling which takes 20-100 seconds. 

I appreciate that changes to the scheduler query won't help any there.

> The mysql portion is still a problem, but not because of the wall clock
> time

I just caused a reschedule to double check my impression. With a a fairly 
modest number of programmes (40 channels) and recording rules, the Big Ugly 
Query took 1.3s on my backend. The total match phase took over 4 seconds. The 
place phase was just 2 seconds. Six seconds is not an eternity I'll admit, 
but it's still slow when the user is waiting for the resulting change on the 
guide grid.

I forget who was responsible, but a dev or contributing user in IRC 
benchmarked the scheduling queries when they were re-written to use 
subqueries. They saw a good improvement. I just wish I could remember who 
that was and what the actual figures were.

-- 
Stuart Morgan