> You cannot simply decide if you cannot decide, you can run tests or turn it off. Having it off by default would be the same as today. Most people activate apc without further thinking.
Regards, Thomas On Fri, Jan 25, 2013 at 1:15 PM, Sebastian Krebs <krebs....@gmail.com> wrote: > > > > 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
