> -----Original Message----- > From: Will Fitch [mailto:wfi...@meetme.com] On Behalf Of Will Fitch > Sent: Friday, January 25, 2013 6:48 PM > To: Zeev Suraski; Rasmus Lerdorf > Cc: Ralf Lang; internals@lists.php.net > Subject: Re: [PHP-DEV] HEADS UP: Upcoming Feature Freeze for PHP 5.5.0 > > > On Jan 25, 2013, at 11:25 AM, Zeev Suraski <z...@zend.com> wrote: > > >> Either by a number of people stepping up to help with the existing > >> APC > > code, or > >> perhaps more realistically making it a priority in PHP 5.6 to > >> streamline > > the > >> engine and the executor for opcode caching and either including a > > heavily > >> simplified version of APC or writing a new one. > >> > >> One thing I can guarantee is that if we add it to core in its current > > condition it > >> will delay 5.5 by 6+ months if not longer. > > > > There's another option. We have the Optimizer+ component which is > > current, a bit faster than APC, worked with PHP 5.4 from the get go > > and already fully supports 5.5 - and now that it's been free for use > > for several years, we'd actually be happy to opensource it and make it > > a part of core. An extra benefit would be that we'd commit to > > maintain it, although of course, community contribution will be very welcome. > > Here too, it's code with a very long history, some of which even > > predates PHP 4.0. But It Works(tm), and we could put some effort into > > cleaning it up and beautifying it. > > I like the idea. If this was implemented in core, and the need for APC opcode > caching disappeared, would APC still be actively maintained for userland > functions (e.g. apc_store, apc_*)?
We could either do that, or create some sort of a merge between the two projects and take the apc_*() APIs into a combined module. I think that would give us the best of both worlds. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
