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
