> 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.
I think it is fine if APC doesn't support all features of PHP. When there is a clear documentation, everybody can decide if he skips some features for better performance. Maybe this also offers room for more optimizations. Regards, Thomas On Fri, Jan 25, 2013 at 9:19 AM, Rasmus Lerdorf <ras...@lerdorf.com> wrote: > On 01/24/2013 11:56 PM, Ralf Lang wrote: >>> From what I understood from Rasmus the biggest challenge with merging APC >>> into core is the fact that the compiler currently isn't built to support >>> opcode caching. One of the challenges he pointed out was some of the >>> MAKE_NOP trickery that can make APC's work a bit more complex than >>> necessary. It's possible to optimize the compiler enough to the point that >>> APC's code could be reduced down to very simple opcode caching, putting >>> less stress on the engine and making it easier to maintain. >> >> I think there was some support for moving APC first from pecl to the PHP >> standard distribution's ext folder before any tighter integration is >> started. > > I'm really not convinced that by moving it to core we will magically get > people to help with it. I have been trying to get people interested for > years, and it hasn't gotten very far. Everyone wants it in the core, but > with a couple of exceptions, nobody is willing to actually work on it to > get it there. > > And I can understand the lack of help. It is probably the most > complicated piece of the entire stack. It is a an op_array juggler doing > a complex dance on a tight rope backwards and blindfolded. It is > essentially multi-threaded in that there are multiple processes all > reading and writing the same chunk of memory while dealing with a > compiler that spits out context-sensitive op_arrays that were never > designed to be cached and executed this way. > > So the learning curve is steep and the bugs are extremely hard to track > down because it is the only PHP component that isn't a perfect sandbox. > A slight memory corruption almost anywhere in any extension can segfault > a dozen requests later with a backtrace that points to the opcode cache > code. Not to mention web servers like Apache that longjmp() on us at the > wrong time. Zend-signals addresses this, but even in 5.4 they aren't > enabled by default because of stability issues and without those no > shared memory opcode cache is safe. > > I firmly believe that we need opcode caching in core. I'm rather > skeptical that simply moving pecl/apc to ext/apc is going to help users > in any way. People have no trouble finding and installing APC today. The > real issue here is robustness and lag time between a PHP release and and > solid APC release and that has to do with resources which are scarce due > to the code complexity. This is the real problem we need to solve. > 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. > > -Rasmus > > -- > 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
