2013/1/25 Thomas Bley <thbley+...@gmail.com> > > 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. >
You cannot simply decide, what features you want to use, when you rely on third-party-libraries from time to time. > > 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 > > -- github.com/KingCrunch
