[mythtv] [mythtv-commits] Ticket #3326: Implement multiple recordings per transport
danielk at cuymedia.net
Fri Oct 5 16:06:06 UTC 2007
On Fri, 2007-10-05 at 16:24 +0100, Stuart Morgan wrote:
> On Friday 05 October 2007 15:56:58 MythTV wrote:
> > I've attached a patch for the range map optimization for scheduling in
> > 3326-multimap-sched-v1.patch. I only yields a 3% speedup after applying
> > the previous optimizations to speed up IsSameProgram checking. It used to
> > yield a 20% speedup. I don't think 3% is worth it so I'm not applying
> > this.
> I'd say that any speedup, no matter how small is worthwhile when you consider
> that the speed of a reschedule, affects the speed at which we update the UI
> to reflect scheduling changes. If I hit 'R' to toggle a recording in the EPG
> it's not until the reschedule is complete that I'll know if that showing will
> be recorded or whether it will conflict. This can be frustratingly slow even
> with the scheduler in trunk.
> 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. The range map directly addresses
that issue, but it turned out that after making some simple
performance to ProgramInfo::IsSameProgram() the extra comparisons
induced by input groups simply weren't a big deal. This optimization
increases memory usage and may have bugs so it's not an unqualified
improvement. Of course, if David or Bruce is interested in using
a range map to avoid program comparisons, the patch is there for
them to try; they may be able to optimize it further. Right now,
MoveHigherRecords() is the best thing to work on to fix worst case
performance. If it were sped up, the range map might make a bigger
difference. Unfortunately, I don't understand that code well enough
to speed MoveHigherRecords() up much; it probably needs a new
algorithm not a new data structure.
> 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. It's the rest of the scheduling which takes 20-100 seconds.
The mysql portion is still a problem, but not because of the wall clock
time, but instead because it causes a priority inversion which in turn
causes glitches in recording and in video playback. The solution to this
is not sub queries, but instead to break great big query into smaller
queries with a yield() between each query. This is NOT something I'm
ready to tackle, I simply don't understand that query well enough, there
are a lot of subtleties to the ordering imposed on the recordings. This
also wouldn't speed up scheduling, just avoid it screwing up playback
and bttv recordings.
More information about the mythtv-dev