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_*)? > I think we can actually do it on time for 5.5.0, or with a relatively > minor delay that might be worth it. I'm sure most users would prefer the > version to take a bit longer if it comes with an opcode cache right off > the bat. > There'll most probably be APIs we'd want to merge from APC, but doing that > should be easy - and we can get the good of both worlds. > > Zeev > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
