[mythtv] Is anybody looking at EITFixUp (eitfixup.cpp)

[Stuart Auchterlonie]

Grackleflint wrote:
> Stuart Auchterlonie <stuarta at squashedfrog.net> wrote:
> 
>> It sounds very nice, but can you make it efficient?
>>
>> The eitfixups get called quite frequently, due to the
>> rate of the incoming EIT data.
>>
>> We moved the eitfixup's from using dynamic regexp's to
>> statically instantiated, so that the regexps wouldn't need
>> to be interpreted at runtime, *purely* because they were
>> taking up too much cpu time.
>>
>> Sourcing our regexps from the database would require a
>> move back to dynamic regexp's.
> 
> A good point.
> 
> I could cache the parsed rule sets so that the performance hit is only 
> taken once per rule set.  I was already planning on parsing a rule set 
> in to an object for processing so it won't be too much effort to cache 
> the result.  This approach still has it's overheads though:
> 
> - a big database and processing hit the first time a rule set is 
> encountered and anytime the cache is invalidated
> - a database hit each EIT scan to validate the cache (small but measurable)

it would need to be done the other way around.
you should be able to preload the fixups required since the channel
and dtv_multiplex tables will have all the information you require
to determine which set of fixups to use.

Then if changes are made to the fixup definitions you would clear
the regexp cache (i'm thinking like is already done for the settings)
The regexp reload hit here is unavoidable.

> - additional memory for the cached rule sets (probably a few K but may 
> be more)
> - additional processing time for running a rules processor instead of 
> hard coding the rules (probably at least double
>  that of hard coding)
> 
> Do the experienced hands think that caching the rule sets will be enough 
> to overcome the performance impact of switching to a dynamic system for 
> EIT fix ups?

My feeling is it would work okay for dvb-t, but would suffer when trying
to process dvb-s EIT streams as they have a much higher data rate.


Stuart