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
