Re: Chunked mempools, a second verdict

On Sat, 5 May 2001, Andres Kroonmaa wrote:

> > memPoolAlloc/Free will only have a negliable impact on performance:
> >
> > if (!mem_stat_counter--)
> > memPoolClean()
>
> 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.
> We can rely on lot of assumptions and try to selftune accoding, but
> after gone through all the pains to get the API style shining, this
> seems like a hacky path for timing purposes.

How about

        if (current_time > next_sync_time) {
                memPoolCalcRates(); // may be somewhat expensive
                next_sync_time = current_time + stats_cycle_len;
        }

With stats_cycle_len being 1 second or more, the above code will have
negligible overhead. This assumes that the memPool library knows what
the current time is (at least approximately). Global time variable or
memPoolUpdateTime() will do that. I doubt it is possible to have nice
rate reporting (and other time-related features like, possibly,
incremental pool cleanup) without current time knowledge.

Alex.
Received on Fri May 04 2001 - 16:51:08 MDT