[asterisk-dev] [Code Review] 3199: scheduler: Remove hashtab usage.

[rmudgett]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3199/#review10836
-----------------------------------------------------------



/trunk/main/sched.c
<https://reviewboard.asterisk.org/r/3199/#comment20424>

    This could be put into its own routine:
    struct sched *sched_find_by_id(int id)
    
    It can then be called by ast_sched_find_data() and ast_sched_when() too.


- rmudgett


On Feb. 7, 2014, 2:24 p.m., Joshua Colp wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3199/
> -----------------------------------------------------------
> 
> (Updated Feb. 7, 2014, 2:24 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> The scheduler currently stores scheduled items in two ways: a hashtab and a heap. The heap is used for actually scheduling while the hashtab is used for fast retrieval under certain circumstances. In practice having the hashtab comes at a cost under normal use. Each time something is scheduled two memory allocations occur: one for the scheduled item itself and one for the hashtab. Each time something is rescheduled the hashtab entry is freed and allocated yet again. If you have a scheduled item which is rescheduled over and over this can be substantial.
> 
> This change removes the hashtab usage and uses the heap for finding things.
> 
> 
> Diffs
> -----
> 
>   /trunk/main/sched.c 405157 
> 
> Diff: https://reviewboard.asterisk.org/r/3199/diff/
> 
> 
> Testing
> -------
> 
> Ran scheduler unit test and also forced the scheduler to get used for Playback.
> 
> 
> Thanks,
> 
> Joshua Colp
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140208/6a2e4cbb/attachment.html>