On Wed, 2012-02-15 at 09:28 +0100, Pavel Březina wrote:
> - if we change the parent of a child of talloc pool to a parent that is
>
> outside of this pool, the whole pool memory will not be freed until
> the child is freed.
This part makes me REALLY nervous. We do a LOT of talloc stealing all
over the place (in the case of the provider lookups, we often steal
request memory onto long-running responder contexts). Using pools could
very easily result in our ending up with a significantly larger memory
footprint. I think we want to be VERY careful about how we use this, if
at all.
That's true. We would need to copy the memory to a new location and then free
the old one. The question is if it would bring any improvement.
Jan's comments about using a pool to handle realloc() loops are
interesting, but it would still require us to have a good sense of how
large a pool we needed in the average case (otherwise it will just end
up resorting to using standard contexts anyway, negating our
advantages).
I don't think so. I mean having the information about average case will
certainly be helpful but if you set lower number, it won't hurt. Even if you
set the size to be twice as large as one element in the array takes, you would
still save 50% of reallocs and that's worth it IMO.
Jan