On Thu, Mar 27, 2008 at 6:35 PM, Taylor Boyko <taylor.boyko at pacificswell.com> wrote: > I see. Is this architecture such for performance reasons? > Portability? Why wouldn't PJSIP just use memory allocation like all > other programs do? It's for both performance and portability reasons. Long time ago memory allocation used to have serious issues with performance, hence we have so many malloc backends (at least on Linux or glibc) all of them claims to have the best performance. With using pool, I saw it can speed up memory operations by up to 30 times, which is massive! >From portability side, the motivation with pjlib is that it was designed to run on systems without OS or libc. With the pool factory, one can just reserve some RAM area for the pool and the whole application will get its heap from this area. No malloc backend is needed. Also if we tailor the pool sizes carefully, potentially we can save memory usage for very small memory devices, since with pool there is no bookkeeping records needed for each memory chunk. Another reason is for fun. Malloc() is soo boring. :) For more rationales please see http://www.pjsip.org/pjlib/docs/html/group__PJ__POOL__GROUP.htm > I suppose the next step, then, is to do what you were proposing > initially, which is to create a separate pool for the call data and > clean it up on call termination. I'm going to dig around and see how > this can be done. Do you have any experience with it? > There is one example here: http://trac.pjsip.org/repos/wiki/FAQ#pjsua-lib-perf Cheers Benny
