Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61103
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain punkave.com designates 209.85.213.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAEZPtU5OKaxyTLSF++gwJUH8Xh76kVg_19GPCGP47fiECCys5g@mail.gmail.com>
References: <CAORXhGJ0NgxXJFoa6YswV5-EsRXqSDNKXTvhdL=7q=Knygr0sQ@mail.gmail.com>
	<4FF2FFBF.8050301@lerdorf.com>
	<CAORXhGKH8u7funSGC-wBtPNe2YMAMNL+0iVrK3m_-NCJ8Ld50g@mail.gmail.com>
	<CAL0xaBHk=x8uaYCcm7eJwJci-iMBND1caFENairj7zaS3EsD1A@mail.gmail.com>
	<CAEZPtU7hHTJrb78ACufYLTnB1y_7JfgAhdECjiwxM-cas4Ardw@mail.gmail.com>
	<4FF31F5A.9010009@lerdorf.com>
	<CAEZPtU5OKaxyTLSF++gwJUH8Xh76kVg_19GPCGP47fiECCys5g@mail.gmail.com>
Date: Wed, 4 Jul 2012 10:37:06 -0400
Message-ID: <CAORXhG+is8g17_91Duc4gjn33=m_0inR7uko3fLU9TaXZxoQWg@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 & pecl yet?
From: tom@punkave.com (Tom Boutell)

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.php@gmail.com> wrote:
> hi Rasmus,
>
> On Tue, Jul 3, 2012 at 6:35 PM, Rasmus Lerdorf <rasmus@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