This repository has been archived on 2022-02-17. You can view files and clone it, but cannot push or open issues or pull requests.

murf aef44ae684 This is the perhaps the biggest, boldest, most daring change I've ever committed to trunk. Forgive me in advance any disruption this may cause, and please, report any problems via the bugtracker. The upside is that this can speed up large dialplans by 20 times (or more). Context, extension, and priority matching are all fairly constant-time searches. I introduce here my hashtables (hashtabs), and a regression for them. I would have used the ast_obj2 tables, but mine are resizeable, and don't need the object destruction capability. The hashtab stuff is well tested and stable. I introduce a data structure, a trie, for extension pattern matching, in which knowledge of all patterns is accumulated, and all matches can be found via a single traversal of the tree. This is per-context. The trie is formed on the first lookup attempt, and stored in the context for future lookups. Destruction routines are in place for hashtabs and the pattern match trie. You can see the contents of the pattern match trie by using the 'dialplan show' cli command when 'core set debug' has been done to put it in debug mode. The pattern tree traversal only traverses those parts of the tree that are interesting. It uses a scoreboard sort of approach to find the best match. The speed of the traversal is more a function of the length of the pattern than the number of patterns in the tree. The tree also contains the CID matching patterns. See the source code comments for details on how everything works. I believe the approach general enough that any issues that might come up involving fine points in the pattern matching algorithm, can be solved by just tweaking things. We shall see. The current pattern matcher is fairly involved, and replicating every nuance of it is difficult. If you find and report problems, I will try to resolve than as quickly as I can. The trie and hashtabs are added to the existing context and exten structs, and none of the old machinery has been removed for the sake of the multitude of functions that use them. In the future, we can (maybe) weed out the linked lists and save some space. ... git-svn-id: http://svn.digium.com/svn/asterisk/trunk@89129 f38db490-d61c-443f-a65b-d21fe96a405b		2007-11-09 16:00:22 +00:00
..
Makefile	This is the perhaps the biggest, boldest, most daring change I've ever committed to trunk. Forgive me in advance any disruption this may cause, and please, report any problems via the bugtracker. The upside is that this can speed up large dialplans by 20 times (or more). Context, extension, and priority matching are all fairly constant-time searches. I introduce here my hashtables (hashtabs), and a regression for them. I would have used the ast_obj2 tables, but mine are resizeable, and don't need the object destruction capability. The hashtab stuff is well tested and stable. I introduce a data structure, a trie, for extension pattern matching, in which knowledge of all patterns is accumulated, and all matches can be found via a single traversal of the tree. This is per-context. The trie is formed on the first lookup attempt, and stored in the context for future lookups. Destruction routines are in place for hashtabs and the pattern match trie. You can see the contents of the pattern match trie by using the 'dialplan show' cli command when 'core set debug' has been done to put it in debug mode. The pattern tree traversal only traverses those parts of the tree that are interesting. It uses a scoreboard sort of approach to find the best match. The speed of the traversal is more a function of the length of the pattern than the number of patterns in the tree. The tree also contains the CID matching patterns. See the source code comments for details on how everything works. I believe the approach general enough that any issues that might come up involving fine points in the pattern matching algorithm, can be solved by just tweaking things. We shall see. The current pattern matcher is fairly involved, and replicating every nuance of it is difficult. If you find and report problems, I will try to resolve than as quickly as I can. The trie and hashtabs are added to the existing context and exten structs, and none of the old machinery has been removed for the sake of the multitude of functions that use them. In the future, we can (maybe) weed out the linked lists and save some space.	2007-11-09 16:00:22 +00:00
ael_main.c	Merged revisions 87168 via svnmerge from	2007-10-26 17:39:39 +00:00
astman.1	git-svn-id: http://svn.digium.com/svn/asterisk/trunk@7221 f38db490-d61c-443f-a65b-d21fe96a405b	2005-11-29 18:24:39 +00:00
astman.c	improve linked-list macros in two ways:	2007-11-08 05:28:47 +00:00
build-extensions-conf.lua	Add pbx_lua as a method of doing extensions	2007-11-02 15:36:34 +00:00
check_expr.c	and then, I noticed the clicompat stuff.	2007-10-17 20:06:28 +00:00
clicompat.c	and then, I noticed the clicompat stuff.	2007-10-17 20:06:28 +00:00
conf2ael.c	Merged revisions 87168 via svnmerge from	2007-10-26 17:39:39 +00:00
expr2.testinput	In regards to changes for 9508, expr2 system choking on floating point numbers, I'm adding this update to round out (no pun intended) and make this FP-capable version of the Expr2 stuff interoperate better with previous integer-only usage, by providing Functions syntax, with 20 builtin functions for floating pt to integer conversions, and some general floating point math routines that might commonly be used also. Along with this, I made it so if a function was not a builtin, it will try and find it in the ast_custom_function list, and if found, execute it and collect the results. Thus, you can call system functions like CDR(), CHANNEL(), etc, from within $\[..\] exprs, without having to wrap them in $\{...\} (curly brace) notation. Did a valgrind on the standalone and made sure there's no mem leaks. Looks good. Updated the docs, too.	2007-07-05 18:15:22 +00:00
extconf.c	This commits the performance mods that give the priority processing engine in the pbx, a 25-30% speed boost. The two updates used, are, first, to merge the ast_exists_extension() and the ast_spawn_extension() where they are called sequentially in a loop in the code, into a slightly upgraded version of ast_spawn_extension(), with a few extra args; and, second, I modified the substitute_variables_helper_full, so it zeroes out the byte after the evaluated string instead of demanding you pre-zero the buffer; I also went thru the code and removed the code that zeroed this buffer before every call to the substitute_variables_helper_full. The first fix provides about a 9% speedup, and the second the rest. These figures come from the 'PIPS' benchmark I describe in blogs, conf. reports, etc.	2007-11-01 22:26:51 +00:00
frame.c	git-svn-id: http://svn.digium.com/svn/asterisk/trunk@7221 f38db490-d61c-443f-a65b-d21fe96a405b	2005-11-29 18:24:39 +00:00
frame.h	git-svn-id: http://svn.digium.com/svn/asterisk/trunk@7221 f38db490-d61c-443f-a65b-d21fe96a405b	2005-11-29 18:24:39 +00:00
hashtest.c	This is the perhaps the biggest, boldest, most daring change I've ever committed to trunk. Forgive me in advance any disruption this may cause, and please, report any problems via the bugtracker. The upside is that this can speed up large dialplans by 20 times (or more). Context, extension, and priority matching are all fairly constant-time searches. I introduce here my hashtables (hashtabs), and a regression for them. I would have used the ast_obj2 tables, but mine are resizeable, and don't need the object destruction capability. The hashtab stuff is well tested and stable. I introduce a data structure, a trie, for extension pattern matching, in which knowledge of all patterns is accumulated, and all matches can be found via a single traversal of the tree. This is per-context. The trie is formed on the first lookup attempt, and stored in the context for future lookups. Destruction routines are in place for hashtabs and the pattern match trie. You can see the contents of the pattern match trie by using the 'dialplan show' cli command when 'core set debug' has been done to put it in debug mode. The pattern tree traversal only traverses those parts of the tree that are interesting. It uses a scoreboard sort of approach to find the best match. The speed of the traversal is more a function of the length of the pattern than the number of patterns in the tree. The tree also contains the CID matching patterns. See the source code comments for details on how everything works. I believe the approach general enough that any issues that might come up involving fine points in the pattern matching algorithm, can be solved by just tweaking things. We shall see. The current pattern matcher is fairly involved, and replicating every nuance of it is difficult. If you find and report problems, I will try to resolve than as quickly as I can. The trie and hashtabs are added to the existing context and exten structs, and none of the old machinery has been removed for the sake of the multitude of functions that use them. In the future, we can (maybe) weed out the linked lists and save some space.	2007-11-09 16:00:22 +00:00
hashtest2.c	UGH... while trying to fix #10995, I found all kinds of cruft in this Makefile. It should all be gone now, and as a side effect hashtest2 now builds with --enable-dev-mode enabled without a host of errors	2007-10-29 22:44:49 +00:00
muted.c	Merged revisions 46067 via svnmerge from	2006-10-24 01:28:45 +00:00
smsq.c	Add another big set of doxygen documentation improvements from snuffy.	2007-08-07 23:04:01 +00:00
stereorize.c	git-svn-id: http://svn.digium.com/svn/asterisk/trunk@7221 f38db490-d61c-443f-a65b-d21fe96a405b	2005-11-29 18:24:39 +00:00
streamplayer.c	Merged revisions 47331 via svnmerge from	2006-11-08 17:06:33 +00:00