> 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 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
