[asterisk-dev] fast-ast2 ready to merge to trunk, is that OK?
mnicholson at digium.com
Mon Nov 5 18:52:29 CST 2007
On Mon, 2007-11-05 at 17:40 -0700, Steve Murphy wrote:
> On Mon, 2007-11-05 at 17:35 -0600, Matthew Nicholson wrote:
> > On Mon, 2007-11-05 at 22:15 +0200, Victor Sergeev wrote:
> > > Steve Murphy wrote:
> > > >
> > > > 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.
> > Steve,
> > If you need help generating the required diaplan code in lua, I am
> > willing to assist you.
> Many thanks! All you have to do is write a small loop to call
> a million times. It needs to record the beginning time, and ending time,
> and report the total time to completion. Uh, to make things even, use a
> var with a million in it, instead of the straight constant. And a var to
> hold the loop count, of course.
So, as far as making things even goes, would this need to be a channel
var or a lua var? I would actually like to do both of them to see the
> Should run rings around AEL... ahem.
> Actually, unless lua is embedded within Asterisk, it might not win;
> especially if it has to any socket communications... but if it's
> executing directly in an asterisk thread, AEL might not have a chance.
Lua runs directly in an asterisk thread.
> Haven't had time to benchmark AGI scripts....
> If you are going to totally replicate the tests, you'll need to
> the full dialplans... I have a set of 25 dialplans: 8 with varying
> of contexts (1,10,50,100,200,300,500,1000), each having one extension,
> and one priority, except the test extension, which has the million loop
> in it.
> The next set of 8 contain one context with a varying number of
> extensions in it.
> (1,10,50,100,200,300,500,1000); in the first extension, the million loop
> should be located.
> The last set of 8 contains one context, and one extension, but a
> variable number
> of NoOp() calls before the loop. (1,10,50,100,200,300,500,1000),
> And, one last dialplan with 1000 contexts, the first having 1000
> extensions, the first having 1000 NoOp(Hello There) calls before the
> million loop.
I will get with you off list to replicate your test suite. I am very
interested in seeing how this turns out. Additional tests for the lua
code would be the performance of mixing extensions.conf and
extensions.lua. Also the total lookup time needed, including the time
before control is passed to extensions.lua would be useful to know.
> If the lua interface uses hashtabs for the contexts/priorities, then
> until they use the "trie" for the extens, the only set of tests to
> show a slowdown should be the set with varying number of extensions.
The lua interface uses lua 'tables' to hold contexts and extensions (the
table is lua's universal data structure). Tables use hash tables for
lookups. Currently the context lookup is done using the context name as
the lookup key, which should amount to a hash table lookup. The
extension match is done by iterating through all available extensions in
Judging by that your assessment should be correct.
More information about the asterisk-dev