[vdr] Problems with 20 Timers

[Klaus Schmidinger]

Chris Warren wrote:
>>You could do some profiling with gprof.
>>To that you need to link vdr with -- hmm -- I think gp (read: 
>>add -lgp when linking), then run it inside gprof (gprof vdr ....).
>>
>>--Stefan
>>
> 
> 84.78%     51.92    51.92    70436     0.00     0.00 
> cSchedule::GetEvent(unsigned short, long) const
> 
> That's the culprit...
> 
> I wonder if it would be worth rewriting cSchedule to store events in a
> binary tree based on time. A double-linked list could be included in the
> nodes pointing to allow for scanning through the schedule in the
> conventional way (for(cEvent *p = events.First()...)
> 
> This would cut down the amount of work required to find an event based on
> time (used for timers, finding now/next events and probably numerous other
> places). Another tree of pointers could be built based on event id, to speed
> up searching based on IDs too.
> 
> 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.

Klaus