[asterisk-dev] chan_sip -- improving the speed of sip reloads

[Steve Murphy]

On Wed, 2007-11-21 at 12:18 -0600, Russell Bryant wrote:
> Steve Murphy wrote:
> > In the IAX2 implementation, really, there were only 2 places where the
> > code iterates that concerned me, and that is in iax2_getpeername(), and
> > iax2_getpeertrunk(). If these functions are (or could be) called
> > frequently, a good alternative is to create another hashtable keyed by
> > the ip/port info so these things can just be directly looked up instead
> > of a linear search. I would think this whether iterators had a problem
> > or not. If they are frequently called, I would go the hashtable route
> > before I would change to a different method of iteration.
> 
> Both of these are called during each call setup.  I do agree that both of them
> could benefit from the use of ao2_callback() instead of the ao2_iterator approach.
> 
> Speaking of chan_iax2 efficiency, another place that could drastically benefit
> from the use of a hash table is the find_callno function.  If you take a look at
> it, you'll see my rant on its problems.  To fix this, we need the IAX2 pvt
> structures in a hash table keyed by the remote end's IP address and port number.
> 
>  * \todo XXX Note that this function contains a very expensive operation that
>  * happens for *every* incoming media frame.  It iterates through every
>  * possible call number, locking and unlocking each one, to try to match the
>  * incoming frame to an active call.  Call numbers can be up to 2^15, 32768.
>  * So, for an call with a local call number of 20000, every incoming audio
>  * frame would require 20000 mutex lock and unlock operations.  Ouch.
>  *
>  * It's a shame that IAX2 media frames carry the source call number instead of
>  * the destination call number.  If they did, this lookup wouldn't be needed.
>  * However, it's too late to change that now.  Instead, we need to come up with
>  * a better way of indexing active calls so that these frequent lookups are not
>  * so expensive.
> 
> This is definitely one of, if not the most offending pieces of code in that
> module.  We really need to fix it ...
> 

Russell--

Just a random thought on the situation, that you probably already have
thought yourself...

One of the fun things about hash tables is that you don't need to
actually store the key in the structure, as long as you can **derive**
it from the other members of the object. For instance, if you have an
object with an ip and port, and you want to use those as a key, you set
up your hash functions like this:

compare_func:
  if (objA.ip == objB.ip && objA.port == objB.port) ...

hash_func:
  return (int)obj.ip + (int)obj.port;

I'd offer to help you do it over the thanksgiving vacation, but I get
this feeling like you're probably half-way thru it right now
anyway... ;)

murf

-- 
Steve Murphy
Software Developer
Digium
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3239 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20071122/9b3851d7/attachment.bin