[mythtv] Understanding the myth source code

[Ed W]

> I don't think anyone is saying improvements can't be made, only that
> people seem to think there is going to be a single point of slowdown
> and in reality it's probably a great many, as you mention.

Agreed (note my comments weren't intentionally directed at you)

> That said, it sounds like you feel you've made some impressive
> optimizations, why not share them with the OP if you don't have the
> time to clean them up for submission yourself? (I'm not being
> facetious, I'm genuinely interested in seeing improvements throughout
> myth, even when I don't use the particular functionality.)
>    

I haven't touched this for about 3 years now so I would have to get in 
and plug away again now.  However, on my previous iteration I was mostly 
playing with buffer sizes and some overly enthusiastic locking in the 
frontend.  The main thing I found useful was to add some instrumentation 
to the code to show the main top level change timings and from that it 
starts to become possible to see where to attack.  I wonder if we added 
some timing wrappers to parts of the frontend (and backend) code it 
wouldn't gather some responses from the users and in turn help a few 
contributors optimise a few bits?  It was stuff like I used (years ago) 
to measure say 1/4 of a second for the frontend just shutting down the 
last stream *before* it even instructed the backend to change channel - 
remove / re-order that or get the backend changing in parallel, etc - 
I'm sure a ton has changed since then, but my channel change times have 
also double/tripled since then, so very likely there is plenty of good 
optimisation to be had for those who look?

I think the OP here is looking at the backend and I agree that this is 
probably where most of the current meat appears to be?  The faster we 
can get something spooling the better, frontend starts to wakeup, 
buffers start to fill, audio/video gets the right params, etc.  Good 
luck with that

I should imagine also a bunch of people could experiment heavily with 
buffer sizes and slim down the amount of buffering considerably using 
some heuristics? Optimising for frontend/backend on the same machine 
might also be possible?

Not looked for far too long, but I really do think there is some scope 
for someone with some time to at least contribute an instrumentation 
patch and hopefully others will dig in and start to tune things?  
Intuitively it seems it should be possible to get a frontend channel 
change experience in the 1-2 second range for DVB-T and perhaps even sub 
1 second for changes on the same mux...

Cheers all

Ed W