Hmm, but the stat=0 optimization is a major one; a cache that didn't offer it would be significantly slower in production for those who know what they're doing, yes?
(I haven't actually tried the stat=0 trick myself yet and don't have performance numbers on its impact. I really ought to though, since hitting an API URL that clears the APC cache as part of deployment should be pretty easy.) On Wed, Jul 4, 2012 at 5:55 AM, Pierre Joye <pierre....@gmail.com> wrote: > hi Rasmus, > > On Tue, Jul 3, 2012 at 6:35 PM, Rasmus Lerdorf <ras...@lerdorf.com> wrote: >> On 07/03/2012 08:17 AM, Pierre Joye wrote: >>> I for one would like to kill all the legacy features or too specific >>> features which are really unusable by any common developers. >>> >>> Other developers may disagree but it makes very hard to maintain APC. >> >> There are really just two big features in APC. The opcode caching and >> the user-cache that sits on top of the same shared memory segment used >> by the opcode cache. > > Right, I wold like to split them tho'. To have two independent memory > for opcodes and user cache. > >> Everything else are just little tweaks that amount >> to very little code. > > Maintenance complexity is not necessary related to the amount of code > but the amount of cases to test. These cases also make very hard for > our users to understand APC and how it behaves (the stat=0 being the > easiest one to understand but causing most issues, for example). > > That's where eAccelerator or xCache do way better, if it works, it > simply works, no magic option or other confusing (for the users) > options. > >> The biggest cleanup we would get moving it to core >> would be the ability to drop all the #ifdef checks for the different >> engine versions since we would obviously only need to support the >> current one. > > We will still have to support current supported versions via PECL. > > > Cheers, > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
