[Asterisk-Dev] sched.c::schedule function can be a bottleneck and is optimised backwards

[Steve Kann]

steve at daviesfam.org wrote:

>Hi,
>
>I've been looking at performance in iax2 for handling registrations.
>
>oprofile revealed that 60-70% of my execution time was in 
>ast_sched_add_variable in sched.c
>
>With lots of registrations, its true that many many tasklets are getting 
>scheduled, but I didn't expect this activity to be my bottleneck.
>
>By inspection, I'm pretty sure that the time is going in schedule().
>
>The logic searches down the schedule queue, looking for the first entry to 
>run later than the new one.  The new one is then inserted there.
>
>It would be much quicker to search the list backwards.  Stands to reason 
>that the new entry is much more likely to go at the end or near to the end 
>of the queue than it is to go near the start.
>
>Thats definitely the case for the example of registrations, but I'm pretty 
>confident that it'll be the case in general, seeing as how time goes 
>forwards.
>
>Agreed to change it around?  I think that the list will need to be made 
>doubly-linked as I need to be able to insert near the end and retrieve 
>from the front.
>  
>

This is exactly what I did with the queue in the new jitterbuffer. The 
list is doubly-linked, and I search from the "end" of the queue when 
inserting new items, and always remove them from the head. Most of the 
time, this leads to just one compare each time.

I would guess the scheduler has a slightly different mix of scheduling 
times, though. There's probably a lot of things scheduled to happen 
within the next few hundred milliseconds, but then also a more varied 
mix of things to do that get spread out over the next 30-60 seconds, or so.

It might be instructive to write someting to dump the scheduler queue, 
and then cook up a few "average" example cases, and dump the queue, and 
see what it looks like.

If you end up with thousands of schedulings in the first 100ms or so, 
and then a thousand or so things spread over the next 30ms, then it 
might make sense to split it up into two queues: a "short" queue, and a 
"long" queue, or something like that.

-SteveK