[asterisk-dev] fast-ast2 ready to merge to trunk, is that OK?

[Victor Sergeev]

Steve Murphy wrote:
> OK, I've been working on this for, what, a year now or so.
>
> And today, I plan to merge it to trunk.
>
> Unless violent objections, or serious flaws in my thinking are
> expressed, that is.
>
> I have blogged on the fast-ast project earlier, you may wish to review
> that
> material. It's changed only slightly. (see
> hattp://www.asterisk.org/node/112)
> (Stupid blog; my nice little graph disappeared!)   !$!@$!@$@$!!!!
>
> I made sure I could do an 'ael reload' without problems, which required
> some detailed attention to the merge_contexts_and_delete() and the
> __ast_context_create functions, so they are looking for the right thing
> in the right places, in the right way.
>
> I also insured the right things happen if you add extensions on the fly
> after
> the initial 'load_module' of ael or extensions.conf. I also insured that
> the new stuff is properly destroyed and freed in the right places.
>
> It all appears to work. So, I'd like to check it in, please.
>
> What's the advantages?
>
> 1. Flat response times in searching for a matching context, exten, and
> priority in the dialplan, which were previously subject to exponential
> slowdowns due to linked list searches. I have made graphs from 1 to 1000
> elements in each category. This means that in a dialplan with 1000
> contexts, and the context we are executing in, has 1000 extensions, and
> in that context, we are executing apps after the 1000th priority, we
> will see a speedup over the old code of roughly 23x. For bigger
> dialplans, the speedup will be greater.  For dialplans with
> over 10,000 extensions, the speedup could be maybe 100x; I haven't
> measured it yet.
>
>   
It'll be interesting to compare it with the same kind of dial plan
written in recently introduced LUA.
Could you include such  comparison in your future benchmarks.

Victor