Re: Chunked mempools, a second verdict

On Sat, May 05, 2001, Henrik Nordstrom wrote:
> Andres Kroonmaa wrote:
>
> > yup. I initially leaned to that too. But 2 problems.
> > Alloc rate can range from 1/min to 500K/sec. At one extreme we'd have
> > time lag of few hundred minutes, at other we'd have heavy overhead,
> > most problem being time lag.
>
> Ok. So lets keep the event then.. not a major thing. Having it
> selfadjusting is nice, but if as you say this code is really used a lot
> then it should be kept as simple as possible. But it also tells that
> there is lots of room for optimization in the code paths.. a average of
> 125+ memory allocations per request is a lot of allocations.

Robert and I are working on that in the newhttp branch.
Hopefully that number will drop significantly.

Remember that in src/store_client.c most storeClientCopy()s are
done with a memAllocate(MEM_CLIENT_SOCK_BUF) to pass to
clientSendMoreData()..

In either modio or commloops I played with a single temp buffer which
was linked to the client state. This cut down on the mallocs a little,
but quite a bit of the mallocing went to the strings on the client
and server (and back? :-) side.

Adrian

-- 
Adrian Chadd			"How could we possibly use sex to get
<adrian@creative.net.au>	  what we want?
			 	   Sex _IS_ what we want!" -- Fraser