[asterisk-dev] Better pattern matching

[John Todd]

At 4:08 PM -0600 2007/8/1, Steve Murphy wrote:
>On Wed, 2007-08-01 at 14:53 -0500, John Lange wrote:
>>  On Wed, 2007-08-01 at 14:48 -0400, Jared Smith wrote:
>>  >  they're worried
>>  > that this will severely impact the time it takes for Asterisk to do
>>  > pattern matching.
>>
>>  There is no reason why Asterisk can't continue to support it's existing
>>  system using the "_" (underscore) to indicate the old system and some
>>  other character (maybe enclose the regex in "/" like many other
>>  languages) to indicated the next expressions is a regex.
>>
>>  That provides complete backwards compatibility, causes zero performance
>>  hit for anyone who doesn't need regex, and accomplishes the goal of
>  > better pattern matching.
>>
>[snip]
>
>I've written a report on the effects of the current algorithm on the
>speed of
>processing in Asterisk. See http://www.asterisk.org/node/112
>
>[snip]
>We might be able to extend the current algorithm to handle a few more
>simple cases without resorting to such huge machinery. We shall see.
>
>murf


I've read the whole thread after this post, and it seems that there 
are a few good suggestions as to how to improve the speed-up of a 
more extensive regular expression matching engine, and I also 
_really_ like the idea of making extension matching a "macro" (using 
a #define) or something similar to what we have with "n" now in 
priority mappings.  That would make life SO much more easier while 
writing dialplan code (no more cut-and-paste a million times!) and is 
100% backwards compatible.

It seems to me, though, that the easiest fix for speed improvement is 
this: make the "extended" regular expression matching only active on 
contexts that require it.  I typically have about 50-100 contexts in 
a dialplan, but only a small number of them actually need to do 
extremely smart things with extension routing, or at least do 
matching and mapping on what an extended regexp would provide.  All 
the other contexts can just use the expression mapping we have now. 
Why not just have each context selectable as being "extended" or 
"normal" expression matching?  I'm OK with taking a 90% speed 
decrease on some of my contexts, but not on all of them.  So just 
make it possible to turn on extended matching on a per-context basis.

By all means, I think we should do whatever is useful to speed up any 
extended regular expression matching.  But for the sake of an easy 
method to implement better pattern matching immediately, this seems 
like a method that will not change existing behaviors and gives the 
benefits of the extended matching.

; this is a normal context
;
[blah]
exten => _X.,1,NoOp(The dialstring is ${EXTEN})



; this is an extended regexp context, as noted by
;  the "*_" prefix in the context name, and this
;  context will run a lot slower than [blah] does
;
[*_blah-plusplus]
exten => ^*NANCY*,1,NoOp(The dialstring contains the string "NANCY")



JT