On Tue, Jan 29, 2013 at 2:52 PM, Rasmus Lerdorf <ras...@lerdorf.com> wrote:
> On 01/29/2013 05:30 AM, Clint Priest wrote: > > > 2) Isn't APC the standard? Is it in such bad shape it is not even being > > considered any longer? > > As it currently stands from a developer participation standpoint it is > not viable. I outlined the issues in a previous post. > > You also have to take into account that most sites can't actually move > to the next release of PHP until APC is stable with it. So effectively > the PHP 5.4 release didn't happen until APC 3.1.13 in September 2012 > which was a full 6 months after PHP 5.4.0. I don't foresee this getting > any better for PHP 5.5. > > In order for PHP releases to actually mean something this is a problem > we have to fix. I honestly don't care which opcode cache implementation > we base a core version on, what I care about is developer buy-in. Dmitry > and Stas being familiar with the code already outnumbers the number of > active core devs working on APC today. > > I understand some of the skepticism and hurt feelings around this from a > few old-timers, but let's move on and see if we can finally push out a > release with solid opcode caching right at the release date. From my > perspective anything up to a 6-month delay would beat the current > situation. > I'm not sure I fully understand this. The RFC claims that Optimizer+ is already *now* fully compatible with PHP 5.5. And that it was also compatible when PHP 5.4 was released. So they lack of a working and free opcode cache clearly wasn't the issue. My guess is rather that the lack of APC support (as in specifically APC and not just some opcode cache) was an issue. Either because people didn't know about alternatives (APC after all is the go-to opcode cache), didn't want to try them or had software tightly integrated with APC (and in particular its user cache). Just to be clear: I fully agree that PHP needs a working opcode cache when PHP 5.5 ships, otherwise adoption will be like 5.4. But I'm not sure what exactly changes between Optimizer+ being in core (enable via configure) and Optimizer+ being in PECL (enable via install). The main point I always saw behind including APC in core is that it would require core developers to maintain it and to update it when doing ZE changes, on their own. This doesn't seem to be a motivation for Optimizer+. Apart from that I see rather little difference between core/pecl. Opcode caching is the kind of thing where the "if it's in pecl nobody will use it" logic does not apply, as people using opcode caches run their own servers. I do get that opcode caching is commonly needed, so it would be nice to have it in core (easier installation?), but I don't see why we should put off the release for one, two, or more months, for that small convenience. Thanks, Nikita
