On 01/25/2013 08:25 AM, Zeev Suraski wrote: > 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.
I would be ok with that. The goal here is opcode cacheing in core. How we get there is less important. The one thing we can do bringing an old codebase into core is to clean it up quite a bit since we'd know the target version. All the ifdefs for older versions can go away, and some of the tricks that need to be done could be shuffled into the compiler/executor to streamline things. I am also not worried about userspace compatibility for things like apc_store/fetch. Any software written to make use of that already has conditional checks around it plus that feature needs a serious re-think anyway. Sharing a lock with op_array handling really doesn't scale. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
