Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65163
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.41 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CA+_UWzr=U3mBW22xSSKfbEswS4-yxtnWWABEre_zbeMXWr83tQ@mail.gmail.com>
References: <slrnkg3ag2.g88.dsp@experimentalworks.net>
	<CAJW__o2gncnxnAGd7M7jZjxGADzt2D9xYQOyhp_797Lebx5JSA@mail.gmail.com>
	<CAL+t6cH6b290+T9=dLp_FFaFCAUiJumx9zvWQNiUr5KfKyunXQ@mail.gmail.com>
	<51023AB1.2010607@b1-systems.de>
	<51024016.4010005@lerdorf.com>
	<CA+_UWzr=U3mBW22xSSKfbEswS4-yxtnWWABEre_zbeMXWr83tQ@mail.gmail.com>
Date: Fri, 25 Jan 2013 13:15:35 +0100
Message-ID: <CALtuQzB3i5DRU9MVwbZLL_t5J-_ZFp4FaX00PRurH_9C+ZVj3g@mail.gmail.com>
To: Thomas Bley <thbley+php@gmail.com>
Cc: PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d043c7b987cf50b04d41be2cc
Subject: Re: [PHP-DEV] HEADS UP: Upcoming Feature Freeze for PHP 5.5.0
From: krebs.seb@gmail.com (Sebastian Krebs)

--f46d043c7b987cf50b04d41be2cc
Content-Type: text/plain; charset=ISO-8859-1

2013/1/25 Thomas Bley <thbley+php@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 <rasmus@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

--f46d043c7b987cf50b04d41be2cc--