4 Commits

Author	SHA1	Message	Date
Steve Murphy	f033e50a15	Don't forget the ASTERISK_VERSION for the sake of the mtx_prof stuff. ... git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89201 65c4cc65-6c06-0410-ace0-fbb531ad65f3	2007-11-12 23:33:55 +00:00
Kevin P. Fleming	c7773aa206	(closes issue #11221) ... Reported by: eliel Patches: utils.Makefile.patch uploaded by eliel (modified by me) (license 64) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89190 65c4cc65-6c06-0410-ace0-fbb531ad65f3	2007-11-12 20:16:13 +00:00
Joshua Colp	098728eb64	Fix building on FreeBSD by including/not including some headers. ... (closes issue #11218) Reported by: ys Patches: trunk89169.diff uploaded by ys (license 281) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89177 65c4cc65-6c06-0410-ace0-fbb531ad65f3	2007-11-12 13:26:45 +00:00
Steve Murphy	a897556f7f	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: https://origsvn.digium.com/svn/asterisk/trunk@89129 65c4cc65-6c06-0410-ace0-fbb531ad65f3	2007-11-09 16:00:22 +00:00