Re: Chunked mempools, a second verdict

On 4 May 2001, at 8:13, Alex Rousskov <rousskov@measurement-factory.com> wrote:

> > How do you use such thing?
>
> I think Henrik answered that already. You might want to look at C++
> STL for more examples.

 well, when you get it, you like it.

> > > Still not sure why do you need this call. Why can't the library do it
> > > on its own, when needed (either via memPoolUpdateTime that Henrik
> > > banned or from inside of other public functions).
> >
> > like what functions? Alloc/Free out of question, they are tuned for
> > performance, and any overhead is unwanted there.
>
> If Alloc/Free is out of the question, then you have to convince Henrik
> that memPoolUpdateTime is a good idea.

 well, not actually that bold, just wanna keep these funcs sporty.

> Personally, I really doubt that
> eliminating a couple of cheap statements from Alloc/Free (to check
> whether stat cycle has ended) will have any impact on Squid speed.

 Well, its actually amazing. Malloc+Free rate can easily go to 400K+/sec
 and above, especially during swaplog maintenance. Consumes upto 50-80%
 of CPU time on PIII-800(!). For memory alloc, kind of not very fast.
 Currently, we do about 125 Pooled Allocs per client request on average.
 At a rate of 200 reqs/sec thats about 50K memPool calls /sec, or
 about 5-10% CPU. not terribly lot, but it is speed sensitive code.
 Adding code there has unclear consequence. Given that code is already
 very minimal, about anything adds there some noticable overhead...
 But sure, if (counter++ == LIMIT) isn't too much.

------------------------------------
 Andres Kroonmaa <andre@online.ee>
 CTO, Delfi Online
 Tel: 6501 731, Fax: 6501 708
 Pärnu mnt. 158, Tallinn,
 11317 Estonia
Received on Fri May 04 2001 - 14:43:34 MDT