On 28 Apr 2001, at 11:09, Henrik Nordstrom <hno@hem.passagen.se> wrote:
> Andres Kroonmaa wrote:
>
> > in lib/MemPool.c:
> > #define DISABLE_POOLS 1
> >
> > will effectively disable pooling and will revert back to pure xcalloc/xfree
> >
> > It only disables memPoolAlloc and memPoolFree. All else is left in.
> > Probably enough for debugging? It would be difficult to rip off all code
> > related to pools, and I think that is not needed.
>
> If DISABLE_POOLS is moved up one level, and when set memPoolAlloc,
> memPoolFree are replaced by macros calling calloc/free then pools are
> fully disabled (the pool initialization is still required to set the
> pool sizes and such, we can't get away from that)
Currently, we have statistics per pool even when pooling is disabled.
We have cachemgr stats about how any type of pool is used. If we redefine
memPoolAlloc/memPoolFree with a macro, we cut the stats out. We can do
that of course, but I guess that it is worth to keep the stats?
> > configure options are more like for endusers, imho. Should we do that?
>
> MemPools is a memory allocator. There may well be that the user has a
> malloc() implementation that is a lot better and faster. Or in case of
> memory leaks he/she might want ot use a garbage collecting malloc while
> waiting for a fix.. There are numerous reasons why one might want to
> disable memory pools, not only debugging.
Ok. Only remains the issue with memPool stats. Should rip that off also?
------------------------------------
Andres Kroonmaa <andre@online.ee>
CTO, Delfi Online
Tel: 6501 731, Fax: 6501 708
Pärnu mnt. 158, Tallinn,
11317 Estonia
Received on Mon Apr 30 2001 - 04:21:03 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:13:51 MST