[Asterisk-Dev] potentially nasty bugs in string pools usage

[Luigi Rizzo]

On Thu, Jan 05, 2006 at 06:13:17AM -0700, Steve Murphy wrote:
...
> I've written code that uses a central pool for string storage. The pool
> area is a linked list of 1 meg memory blocks. Each string is registered
> via a hash table. If a new string to be entered is bigger than what will
> fit in the memory pool, a new block is allocated, and it is put there.
> No realloc, no changing of all the string addresses. And not that hard
> to implement.
> 
> In the application I did this for, I found a 10:1 ratio of commonality
> of strings entered. Thus, the savings on heap space of about 90%... your
> mileage may vary considerably, but in general, string pools like this
> are great, they reduce memory requirements, they speed things up by not
> calling malloc/free as much, they reduce the complexity of your
> interface, as far as copying a string vs. storing the address of the
> string type issues. 

what you describe is very similar to what kevin told (or emailed)
some time ago he wanted to do - share common strings.

One thing one has to be very careful about, though, is that
asterisk uses a lot of threads and if the pools are shared
among different threads (which i believe is the only way
you can save on repeated strings)
then you need to lock accesses to the pool, which in the end
is the same kind of overhead that you have with malloc.

but anyways - i like the approach. i am just warning about
the issues in the current implementation.

cheers
luigi