[vdr] Problems with 20 Timers

Klaus Schmidinger Klaus.Schmidinger at cadsoft.de
Sun Feb 27 12:44:13 CET 2005


Chris Warren wrote:
>>>What do people think, would it be worth me writing a patch?
>>
>>I don't think we should make things more complicated than necessary.
>>
>>My VDR has over 30 timers and I don't have any problems with 
>>excessive latency.
>>
> 
> I just did a (very quick and hacky) comparason - I added 2 std::maps to
> cSchedule:
>   std::map<u_int16_t,cEvent*> eventIDMap;
>   std::map<time_t,cEvent*> eventStartTimeMap;
> 
> By modifying cSchedule::AddEvent and cSchedule::GetEvent as described below,
> I managed to cut the most CPU intensive function's execution time to an 80th
> of the original! (from 83.79% of CPU time down to 1.12%!)
> 
>                    %   cumulative   self              self     total
>                   time   seconds   seconds    calls   s/call   s/call
> vdr_orig.profile: 83.79     51.93    51.93    70436     0.00     0.00
> cSchedule::GetEvent(unsigned short, long) const
>  vdr_mod.profile:  1.12      7.98     0.11    70436     0.00     0.00
> cSchedule::GetEvent(unsigned short, long) const
> 
> I know it adds a little complexity to things, but with such an improvement
> in lookup speed, maybe its worth looking at replacing the lists with a tree?
> 
> Chris

The cSchedule::GetEvent() function is only called from eit.c, which AFAICS
should be independent of the number of timers you have defined.

Since you are only observing these long latency times if there are many
timers, I would assume that the actual problem must be somewhere else.
Could you put a few debug outputs into the main loop of VDR to see where
exactly it spends all that time?

Klaus



More information about the vdr mailing list