[asterisk-dev] Asterisk Media Performance

[David Lee (digium)]

On Jan 6, 2014, at 11:54 AM, Joshua Colp <jcolp at digium.com> wrote:

> 1. Make ast_format an ao2 object
> 
> I think what needs to happen is that ast_format becomes an immutable ao2 reference counted object. Copying becomes bumping the reference count and returning it.
> 
> Additional related stuff can be attached and guaranteed that it will be disposed of. This can include an actual list of attributes, and a pointer to the format negotiatior. As a result operations become faster to do and memory usage goes down.

+1 for immutable objects.

> 2. Audit format usage
> 
> Times have changed and what we can do with Asterisk has also. We need to look at how we are using formats internally and improve/optimize/change them. A perfect example is the format one I used previously. Even though copying an ast_format would become cheap there is no need to do it on every read frame. Everything format related should be fast and quick.

Agreed. In the media path, every little bit helps.

> 3. Be less reactive
> 
> We need to determine something has changed once (such as the format of incoming media) and notify everything else involved. Reacting using the same (or potentially more expensive) comparison logic at different points in the chain is not needed.

Synchronizing the notifications with the format change may be tricky. If we’re not careful, we could end up in the situation where 1) the format changes but some bit of code gets the notification about the change too late or 2) we end up with extra locks/contention in the media path due to format change notifications.

Another option would be structuring ast_format so that comparisons are cheap. If it’s a refcounted immutable object, we might even be able to do it simply with a pointer comparison (or, at the very least, the compare function can be fast if comparing an ast_format with itself).

Of course, I say that without actually looking at the code. Maybe there are other reasons to switch from reactive to notifications, or my concerns about extra locks and late notifications are just FUD. Just something to think about.

-- 
David M. Lee
Digium, Inc. | Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at:  www.digium.com  & www.asterisk.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140106/95a404da/attachment.html>