Re: [APC-DEV] APC b0rkage upcoming
[email protected] (Brian Shire) Tue, 8 Jan 2008 12:59:24 -0800
| Newsgroups | php.apc.dev |
|---|---|
| Message-ID | <[email protected]> |
Thanks for the overview, I was just looking at the code wondering exactly how it was going to be pieced together. I think having the pool allocation may help me experiment with other projects I've had on my mind as well. This sounds great, thanks! -shire On Jan 8, 2008, at 10:38 AM, Gopal V wrote: > Rasmus Lerdorf wrote: >> I know we have talked about it privately, but it might be a good >> idea to give folks on this list a summary of the goals of the >> pooling mechanism. > > Yup, the pool idea has been in my head for quite a while now. It's > there > to avoid a lock call for every allocation in the system. > > Initially, it was supposed to be per-process, but it has been reworked > to be per-cache entry. Every entry holds a pool and allocates all > memory > required from the pool, which pulls in 4/8k blocks. This should > speed up > the allocation operation, but that's not the key problem I'm trying to > fix. > > More importantly, most segvs in APC seem to happen during cache full > conditions when the cache expunge is being performed. Having a pool > essentially reduces all free calls into just deallocating the pool > blocks (i.e 1+4 sma_free calls for 16k of memory). > > It'll also reduce the cruft of the cleanup code whenever there's an > allocation failure and indirectly ensure that there are no memory > leaks. > > Hope all that made sense. > > Cheers, > Gopal > -- > If I learn from my mistakes, pretty soon I'll know everything > > -- > APC Development Mailing List (http://pecl.php.net/APC) > To unsubscribe, visit: http://www.php.net/unsub.php >