Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC] Integrating Zend Optimizer+ into the PHP distribution »

[RFC] Integrating Zend Optimizer+ into the PHP distribution

php.internals

Zeev Suraski

13 years ago
All, Following the discussion at the end of last week, I prepared a draft RFC for the inclusion of Optimizer+ in PHP. In parallel we’re in the process of prepping the source code for independent public consumption, which I hope we can be done with by the end of next week, hopefully sooner. https://wiki.php.net/rfc/optimizerplus Comments welcome! Zeev

Pierre Joye

13 years ago
hi Zeev! On Tue, Jan 29, 2013 at 9:03 AM, Zeev Suraski <zeev@zend.com> wrote:
> All, > > > > Following the discussion at the end of last week, I prepared a draft RFC > for the inclusion of Optimizer+ in PHP. > > In parallel we’re in the process of prepping the source code for > independent public consumption, which I hope we can be done with by the end > of next week, hopefully sooner.
Thanks!
> https://wiki.php.net/rfc/optimizerplus > > > > Comments welcome!
One important part missing is the actual compatibility/support of thread safe PHP. I know that Zend mostly care about NTS since quite some time and that worries me a lot to bundle something that is not working well in thread safe mode. I would consider that as a stopping point. I mean, not to stop its inclusion, but to release 5.5.0 with it without optimizer working as good as APC in ts mode. Cheers,
-- Pierre @pierrejoye

Zeev Suraski

13 years ago
> One important part missing is the actual compatibility/support of thread
safe
> PHP. I know that Zend mostly care about NTS since quite some time and
that
> worries me a lot to bundle something that is not working well in thread
safe
> mode. I would consider that as a stopping point. I mean, not to stop its
inclusion,
> but to release 5.5.0 with it without optimizer working as good as APC in
ts
> mode.
It's mentioned in the RFC - but I think we should be able to (re)add NTS support pretty quickly. Zeev

Laruence

13 years ago
On Tue, Jan 29, 2013 at 4:21 PM, Zeev Suraski <zeev@zend.com> wrote:
>> One important part missing is the actual compatibility/support of thread > safe >> PHP. I know that Zend mostly care about NTS since quite some time and > that >> worries me a lot to bundle something that is not working well in thread > safe >> mode. I would consider that as a stopping point. I mean, not to stop its > inclusion, >> but to release 5.5.0 with it without optimizer working as good as APC in > ts >> mode. > > It's mentioned in the RFC - but I think we should be able to (re)add NTS > support pretty quickly.
Hey: my problem gone. ignore my previous mail thanks
> > Zeev > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
-- Laruence Xinchen Hui http://www.laruence.com/

Ryan McCue

13 years ago
Zeev Suraski wrote:
> Following the discussion at the end of last week, I prepared a draft RFC > for the inclusion of Optimizer+ in PHP.
Hey Zeev, I see in the Benchmarks you tested with WordPress 2.1.1, however this release is roughly 5 years old. Is it possible to get an updated test with 3.5.1 (the latest release)? (My guess is that it will show WP being slower and with a more dramatic improvement.) Thanks,
-- Ryan McCue <http://ryanmccue.info/>

Zeev Suraski

13 years ago
> -----Original Message----- > From: Ryan McCue [mailto:lists@rotorised.com] > Sent: Tuesday, January 29, 2013 10:13 AM > To: Zeev Suraski > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP > distribution > > Zeev Suraski wrote: > > Following the discussion at the end of last week, I prepared a draft > > RFC for the inclusion of Optimizer+ in PHP. > > Hey Zeev, > > I see in the Benchmarks you tested with WordPress 2.1.1, however this > release > is roughly 5 years old. Is it possible to get an updated test with 3.5.1 > (the latest > release)?
You'd notice the entire test suite is more than a bit old :) It's been our standard test suite for years so that we can keep comparing apples to apples. We can definitely run tests on newer versions - and once we open it up I think it'd be great if people contribute some of their own benchmarks!
> (My guess is that it will show WP being slower and with a more dramatic > improvement.)
By the way, I just realized the % gain wasn't all that self-explanatory - it's vs. APC, not vs. plain PHP. I improved the doc to reflect both gains vs. plain PHP and vs. APC. Thanks for the feedback! Zeev

Ivan Enderlin @ Hoa

13 years ago
On 29/01/13 09:30, Zeev Suraski wrote:
> [snip] >> (My guess is that it will show WP being slower and with a more dramatic >> improvement.) > By the way, I just realized the % gain wasn't all that self-explanatory - > it's vs. APC, not vs. plain PHP. I improved the doc to reflect both gains > vs. plain PHP and vs. APC.
It's better now ;-). Thank you for the contribution. It's a great news! Can APC and Optimizer+ work in duo or share some features?
-- Ivan Enderlin Developer of Hoa http://hoa-project.net/ PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis) http://disc.univ-fcomte.fr/ and http://www.inria.fr/ Member of HTML and WebApps Working Group of W3C http://w3.org/

Laruence

13 years ago
On Tue, Jan 29, 2013 at 4:33 PM, Ivan Enderlin @ Hoa <ivan.enderlin@hoa-project.net> wrote:
> On 29/01/13 09:30, Zeev Suraski wrote: >> >> [snip] >> >>> (My guess is that it will show WP being slower and with a more dramatic >>> improvement.) >> >> By the way, I just realized the % gain wasn't all that self-explanatory - >> it's vs. APC, not vs. plain PHP. I improved the doc to reflect both gains >> vs. plain PHP and vs. APC. > > It's better now ;-). > > Thank you for the contribution. It's a great news! Can APC and Optimizer+ > work in duo or share some features?
If O+ became opensource, I think it can be done by lots contributors.. :) thanks
> > -- > Ivan Enderlin > Developer of Hoa > http://hoa-project.net/ > > PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis) > http://disc.univ-fcomte.fr/ and http://www.inria.fr/ > > Member of HTML and WebApps Working Group of W3C > http://w3.org/ > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
-- Laruence Xinchen Hui http://www.laruence.com/

netroby

13 years ago
On 2013/1/29 16:38, Laruence wrote:
> On Tue, Jan 29, 2013 at 4:33 PM, Ivan Enderlin @ Hoa > <ivan.enderlin@hoa-project.net> wrote: >> On 29/01/13 09:30, Zeev Suraski wrote: >>> [snip] >>> >>>> (My guess is that it will show WP being slower and with a more dramatic >>>> improvement.) >>> By the way, I just realized the % gain wasn't all that self-explanatory - >>> it's vs. APC, not vs. plain PHP. I improved the doc to reflect both gains >>> vs. plain PHP and vs. APC. >> It's better now ;-). >> >> Thank you for the contribution. It's a great news! Can APC and Optimizer+ >> work in duo or share some features? > If O+ became opensource, I think it can be done by lots contributors.. :) > > thanks >> -- >> Ivan Enderlin >> Developer of Hoa >> http://hoa-project.net/ >> >> PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis) >> http://disc.univ-fcomte.fr/ and http://www.inria.fr/ >> >> Member of HTML and WebApps Working Group of W3C >> http://w3.org/ >> >> >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> > >
Good news, if Optimizer+ will be integrated to PHP, that's amazing improvement. I vote: Integrate Optimizer+ intoPHP5.5.0, allow up to 2 months delay why we could waiting ? because PHP 5.4 is stable for production environment. we could wait for more bit long time. the big improvement is better than fast release. we do not need release for release. no sense. why not take us some surprise.
-- Appreciate your time. ---------------------------- Netroby

Martin Keckeis

13 years ago
From the perspective of the end-user this would be really great! If it could really be done in 2 months -> wait for it. best regards.

Victor Berchet

13 years ago
On 01/29/2013 10:47 AM, Martin Keckeis wrote:
> From the perspective of the end-user this would be really great! > If it could really be done in 2 months -> wait for it. >
Why should we break the PHP release process by 2 months+ to include O+ ? There are alternatives (APC to name one) and O+ might also be used on top of the core (I don't know it to be able to tell). I think waiting 10 months (12-2) is preferrable and O+ would go in the next PHP release (if accepted). There is really no point in delaying a relase for a feature (vs a bug fix) - even more when substitutes exist. My 2 cents, Victor

Larry Garfield

13 years ago
On 1/29/13 3:47 AM, Martin Keckeis wrote:
> From the perspective of the end-user this would be really great! > If it could really be done in 2 months -> wait for it. > > best regards.
Considering the importance of opcode caches to any serious project these days, I'd say a 2 month delay to get an integrated opcode cache working on release day is absolutely worth it. I cannot speak to the relative merits of APC vs. O+, or how reasonable that timeframe is, but if it is an accurate estimate then from a userland perspective it would be a good investment. (The "optimize for APC" vs. "optimize for shared host with no APC" debate comes up in Drupal on a regular basis; being able to count on one would allow us to optimize our own code far better.) I entirely appreciate Anthony's concern about rule bending, but I think this is a "feature request" at a level that such bending can be considered. --Larry Garfield

Christopher Jones

13 years ago
On 01/29/2013 12:30 AM, Zeev Suraski wrote:
> By the way, I just realized the % gain wasn't all that self-explanatory - > it's vs. APC, not vs. plain PHP. I improved the doc to reflect both gains > vs. plain PHP and vs. APC. > > Thanks for the feedback! > > Zeev >
Zeev, It would be useful to link to the current Optimizer+ doc from the RFC. I believe the link is http://static.zend.com/topics/Zend-Optimizer-User-Guide-v330-new.pdf Can you comment (in the RFC) on differences that the open source code may have from this documentation e.g. on what Zend Guard integration will be included, or what obsolete features you might clean out? I think an RFC should clearly state what the feature does and doesn't work with. I.e. for this RFC list whether CLI, FastCGI, ZTS etc work. Can you list potential platform or extension (XDebug) portability issues? The RFC still mentions Pierre helping with ZTS, which I believe is a left-over comment?? Since the releae time-frame is an issue that may affect voting, the RFC should also contain more details on what needs integrating. Chris
-- christopher.jones@oracle.com http://twitter.com/ghrd Newly updated, free PHP & Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html

Rasmus Lerdorf

13 years ago
On 01/29/2013 04:17 PM, Christopher Jones wrote:
> It would be useful to link to the current Optimizer+ doc from the RFC. > I believe the link is > http://static.zend.com/topics/Zend-Optimizer-User-Guide-v330-new.pdf
Different beast. Something like this is more apt: http://files.zend.com/help/previous-version/Zend-Server-5-Community-Edition/zendoptimizerplus.html which shows the dreaded zend_optimizerplus.inherited_hack which mimics APC's autofilter hack. I'd love to get rid of this particular bit of confusion/code complexity on the integration.
> Can you comment (in the RFC) on differences that the open source code > may have from this documentation e.g. on what Zend Guard integration > will be included, or what obsolete features you might clean out?
Again, you are talking about a different product. Ignore any Zend Guard stuff.
> Can you list potential platform or extension (XDebug) portability > issues?
XDebug together with an opcode cache is always a shaky thing and not something we should be too concerned about. You would never want to run both in production. It would be good if they didn't clobber each other for dev environment purposes, but I am sure we can figure that out. -Rasmus

Stas Malyshev

13 years ago
Hi!
> which shows the dreaded zend_optimizerplus.inherited_hack which mimics > APC's autofilter hack. I'd love to get rid of this particular bit of > confusion/code complexity on the integration.
Ohh, this one. IIRC that has to do with conditional definition of classes and the fact that script may be compiled in one environment but loaded in another, which may create difference in class tables, especially combined with early binding for inherited classes. Getting rid of it is not that easy until people stop writing code like: if($foo) return; class Foo extends Bar {} which would work differently depending on if Bar is defined or not.
> XDebug together with an opcode cache is always a shaky thing and not > something we should be too concerned about. You would never want to run > both in production. It would be good if they didn't clobber each other > for dev environment purposes, but I am sure we can figure that out.
Yeah, it is a good idea for debugger to turn off any caching when activated. I think given proper .ini switches it can be easily arranged.
-- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227

Rasmus Lerdorf

13 years ago
On 01/29/2013 04:47 PM, Stas Malyshev wrote:
> Hi! > >> which shows the dreaded zend_optimizerplus.inherited_hack which mimics >> APC's autofilter hack. I'd love to get rid of this particular bit of >> confusion/code complexity on the integration. > > Ohh, this one. IIRC that has to do with conditional definition of > classes and the fact that script may be compiled in one environment but > loaded in another, which may create difference in class tables, > especially combined with early binding for inherited classes. Getting > rid of it is not that easy until people stop writing code like: > if($foo) return; > class Foo extends Bar {} > which would work differently depending on if Bar is defined or not.
Yes, I am quite familiar with it since we had to handle this in APC too. But I don't think getting rid of it is that hard. It obviously can't be done in the opcode cache because by the time the compiler hands us the op_array we have already lost the FETCH_CLASS opcode which we may or may not need. We need to look at whether that MAKE_NOP() call in the compiler is actually a worthwhile optimization in a future where most people will be running an opcode cache by default. This is one of the prime examples of making the compiler more opcode cache friendly. Yes, it may be at the slight expense of non-opcode cache performance, but with a bundled opcode cache implementation that should be less of a worry. -Rasmus

Terry Ellison

13 years ago
On 30/01/13 00:54, Rasmus Lerdorf wrote:
> On 01/29/2013 04:47 PM, Stas Malyshev wrote: >> Hi! >> >>> which shows the dreaded zend_optimizerplus.inherited_hack which mimics >>> APC's autofilter hack. I'd love to get rid of this particular bit of >>> confusion/code complexity on the integration. >> Ohh, this one. IIRC that has to do with conditional definition of >> classes and the fact that script may be compiled in one environment but >> loaded in another, which may create difference in class tables, >> especially combined with early binding for inherited classes. Getting >> rid of it is not that easy until people stop writing code like: >> if($foo) return; >> class Foo extends Bar {} >> which would work differently depending on if Bar is defined or not. > Yes, I am quite familiar with it since we had to handle this in APC too. > But I don't think getting rid of it is that hard. It obviously can't be > done in the opcode cache because by the time the compiler hands us the > op_array we have already lost the FETCH_CLASS opcode which we may or may > not need. We need to look at whether that MAKE_NOP() call in the > compiler is actually a worthwhile optimization in a future where most > people will be running an opcode cache by default. > > This is one of the prime examples of making the compiler more opcode > cache friendly. Yes, it may be at the slight expense of non-opcode cache > performance, but with a bundled opcode cache implementation that should > be less of a worry.
+1. This one makes no sense to me as it simply hoists the zend_do_inheritance() from runtime binding to compile-time, and this binding has to be backed out by any opcode cache to work properly. It might save a few microseconds per class declaration in non-cached performance, but add factors more to cached performance. Why do this?

Rasmus Lerdorf

13 years ago
On 01/31/2013 01:22 AM, Terry Ellison wrote:
> On 30/01/13 00:54, Rasmus Lerdorf wrote: >> On 01/29/2013 04:47 PM, Stas Malyshev wrote: >>> Hi! >>> >>>> which shows the dreaded zend_optimizerplus.inherited_hack which mimics >>>> APC's autofilter hack. I'd love to get rid of this particular bit of >>>> confusion/code complexity on the integration. >>> Ohh, this one. IIRC that has to do with conditional definition of >>> classes and the fact that script may be compiled in one environment but >>> loaded in another, which may create difference in class tables, >>> especially combined with early binding for inherited classes. Getting >>> rid of it is not that easy until people stop writing code like: >>> if($foo) return; >>> class Foo extends Bar {} >>> which would work differently depending on if Bar is defined or not. >> Yes, I am quite familiar with it since we had to handle this in APC too. >> But I don't think getting rid of it is that hard. It obviously can't be >> done in the opcode cache because by the time the compiler hands us the >> op_array we have already lost the FETCH_CLASS opcode which we may or may >> not need. We need to look at whether that MAKE_NOP() call in the >> compiler is actually a worthwhile optimization in a future where most >> people will be running an opcode cache by default. >> >> This is one of the prime examples of making the compiler more opcode >> cache friendly. Yes, it may be at the slight expense of non-opcode cache >> performance, but with a bundled opcode cache implementation that should >> be less of a worry. > +1. This one makes no sense to me as it simply hoists the > zend_do_inheritance() from runtime binding to compile-time, and this > binding has to be backed out by any opcode cache to work properly. It > might save a few microseconds per class declaration in non-cached > performance, but add factors more to cached performance. Why do this?
I agree. And the code doesn't have to be as silly as the example Stas gave. Something as simple as this will hit it: indexA includes child1 and child2 which both extend parent1 indexB includes only child2 Assuming these are all in different files, if you hit indexA first, by the time the compiler gets to child2 parent1 already exists because child1 inheriting from it brought it in so it will be compiled without the FETCH_CLASS opcode. But then you hit the indexB entry point and now the compiled child2 is used in a context that doesn't already provide parent1 so the cached opcodes can't be used here. Of course, if on an empty cache the indexB entry point is hit before the indexA entry point, then everything is fine. child2 will be compiled with the "FETCH_CLASS parent1" intact and this version can be used in both contexts. This is the kind of thing I really don't want to have to explain to people with an integrated cache solution. It is a level of detail the user should never hit. -Rasmus

Christopher Jones

13 years ago
On 01/29/2013 04:27 PM, Rasmus Lerdorf wrote:
> On 01/29/2013 04:17 PM, Christopher Jones wrote: >> It would be useful to link to the current Optimizer+ doc from the RFC. >> I believe the link is >> http://static.zend.com/topics/Zend-Optimizer-User-Guide-v330-new.pdf > > Different beast. Something like this is more apt: > > http://files.zend.com/help/previous-version/Zend-Server-5-Community-Edition/zendoptimizerplus.html
Ah, ack. The PECL extension and/or configure directive should use a better name. This confusion reinforces my main point: the RFC needs more detail about what PHP will end up having.
>> Can you list potential platform or extension (XDebug) portability >> issues? > > XDebug together with an opcode cache is always a shaky thing and not > something we should be too concerned about. You would never want to run > both in production. It would be good if they didn't clobber each other > for dev environment purposes, but I am sure we can figure that out.
This is the kind of info the RFC (and then user doc) should have. Chris
-- christopher.jones@oracle.com http://twitter.com/ghrd Newly updated, free PHP & Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html

Zeev Suraski

13 years ago
> > XDebug together with an opcode cache is always a shaky thing and not > > something we should be too concerned about. You would never want to > > run both in production. It would be good if they didn't clobber each > > other for dev environment purposes, but I am sure we can figure that > > out. > > This is the kind of info the RFC (and then user doc) should have.
It should be easy to implement the same behavior we have with Zend Debugger today also with Xdebug. The debugger essentially intercepts the compile() callback before Optimizer+, and if it determines that the present request should run through the debugger - it bypasses the Optimizer+ altogether and calls directly into zend_compile_file(). I'll update the RFC that it should be possible to integrate it nicely with any other modules. Zeev

Zeev Suraski

13 years ago
> This is the kind of info the RFC (and then user doc) should have.
I updated the RFC with two extra sections - 'what's an opcode cache', and 'interaction with other plugins'. https://wiki.php.net/rfc/optimizerplus Zeev

John Carter

13 years ago
Hi Zeev, Specifically would it continue to work with the Zend Guard decoder (as it does now)? Thanks, John. -----Original Message----- From: Zeev Suraski [mailto:zeev@zend.com] Sent: 30 January 2013 14:48 To: Christopher Jones Cc: internals@lists.php.net Subject: RE: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
> This is the kind of info the RFC (and then user doc) should have.
I updated the RFC with two extra sections - 'what's an opcode cache', and 'interaction with other plugins'. https://wiki.php.net/rfc/optimizerplus Zeev
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Zeev Suraski

13 years ago
On 30 בינו 2013, at 16:57, John Carter <jcarter@identitynetworks.com> wrote:
> Hi Zeev, > > Specifically would it continue to work with the Zend Guard decoder (as it does now)?
Our (Zend's) goal would be yes. Zeev

Christopher Jones

13 years ago
On 01/30/2013 06:47 AM, Zeev Suraski wrote:
>> This is the kind of info the RFC (and then user doc) should have. > > I updated the RFC with two extra sections - 'what's an opcode cache',
This section extremely general and doesn't explain what the expected feature set might look like. I'm not asking for absolute certainties, just a technical description of what is and isn't the goal. Is it the complete Optimizer+, are there potential cleanups, do you see it being enabled (if not in PECL) or disabled by default, etc. Did I miss seeing the link to the current optimizer+ documentation? http://files.zend.com/help/previous-version/Zend-Server-5-Community-Edition/zendoptimizerplus.html (thanks Rasmus) Your email comment to John Carter about Zend Guard decoder is also not (yet) in the RFC. Chris
> and 'interaction with other plugins'. > > https://wiki.php.net/rfc/optimizerplus > > Zeev >
-- christopher.jones@oracle.com http://twitter.com/ghrd Newly updated, free PHP & Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html

Zeev Suraski

13 years ago
Chris, We're talking about a very specialized piece of software - an opcode cache - nothing more, nothing less. It's not going to do anything beyond implementing the concept of an opcode cache in php - no extra features. Rasmus pointed out correctly that this component has nothing to do with the Optimizer (sans +). It will also not have any special interaction with Zend Guard, beyond perhaps the same mechanisms I mentioned might be useful for debuggers (controlling the order of compile/exec callbacks, already in the RFC). Supporting Zend Guard would be Zend's headache - not php.net's - and wouldn't require any special treatment. At the end of the day it's supposed to integrate cleanly into php without any negative impact - not on functionality nor compatibility. In terms of what integration would entail - my intent was that integration means that it's on by default. I'll clarify that in the RFC, unless people think we should put that up for discussion..? Sent from my mobile On 1 בפבר 2013, at 08:48, Christopher Jones <christopher.jones@oracle.com> wrote: On 01/30/2013 06:47 AM, Zeev Suraski wrote: This is the kind of info the RFC (and then user doc) should have. I updated the RFC with two extra sections - 'what's an opcode cache', This section extremely general and doesn't explain what the expected feature set might look like. I'm not asking for absolute certainties, just a technical description of what is and isn't the goal. Is it the complete Optimizer+, are there potential cleanups, do you see it being enabled (if not in PECL) or disabled by default, etc. Did I miss seeing the link to the current optimizer+ documentation? http://files.zend.com/help/previous-version/Zend-Server-5-Community-Edition/zendoptimizerplus.html (thanks Rasmus) Your email comment to John Carter about Zend Guard decoder is also not (yet) in the RFC. Chris and 'interaction with other plugins'. https://wiki.php.net/rfc/optimizerplus Zeev
-- christopher.jones@oracle.com http://twitter.com/ghrd Newly updated, free PHP & Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html

Rasmus Lerdorf

13 years ago
On 02/01/2013 12:38 AM, Zeev Suraski wrote:
> In terms of what integration would entail - my intent was that integration > means that it's on by default. I'll clarify that in the RFC, unless people > think we should put that up for discussion..?
The hardest thing about that is figuring out the defaults. Setting the shared memory segment size being the primary thing. But if a reset in ZO is low-overhead, I suppose setting a conservatively low cache size isn't going to cause too many problems. With APC because of its memory manager, once the segment starts to fill up things start to slow down a bit as it ends up spending time hunting for free blocks to use. Also, if we are going to turn it on by default I'd really like to get rid of zend_optimizerplus.inherited_hack and zend_optimizerplus.dups_fix since they are both quite hard to explain to users and hit things a user really shouldn't have to concern themselves about. With the integration we should be able to convince the compiler to give us op_arrays we don't need to have hacks for here. -Rasmus

Pierre Joye

13 years ago
On Wed, Jan 30, 2013 at 1:17 AM, Christopher Jones <christopher.jones@oracle.com> wrote:
> The RFC still mentions Pierre helping with ZTS, which I believe is a > left-over comment??
No, it is on purpose and a pro for those worrying about ZTS. Cheers,
-- Pierre @pierrejoye

Laruence

13 years ago
On Tue, Jan 29, 2013 at 4:03 PM, Zeev Suraski <zeev@zend.com> wrote:
> All, > > > > Following the discussion at the end of last week, I prepared a draft RFC > for the inclusion of Optimizer+ in PHP. > > In parallel we’re in the process of prepping the source code for > independent public consumption, which I hope we can be done with by the end > of next week, hopefully sooner.
Thanks! It's great. however, it's a little not perfect that no ZTS supports. :)
> > > > https://wiki.php.net/rfc/optimizerplus > > > > Comments welcome! > > > > Zeev
-- Laruence Xinchen Hui http://www.laruence.com/

Florin Razvan Patan

13 years ago
Thank you for this great initiative! As a user, I could definitely wait for 2-3 more months and get a good implementation/integration of this rather that have to wait for at least one year. I think it would also be nice if this could come as default enabled since this way people would be able to notice the advantages of having it enabled. Or you can run a survey on php.net to see what are the options. I do have one thing to ask you about this. If we do wait 2 months, will the underlaying changes be able to integrate easy with APC/XCache/eAccelerator/others? Opcodes are a must for large traffic websites like those I'm working on right now, so we clearly want to have such a thing installed on our servers as soon as we install a new PHP version. But if including O+ will mean that APC gets delayed 6+ months (see PHP 5.4) it would be a show stopper for us upgrading to PHP 5.5. Our upgrade process is like this: be at least one year on market to iron out major/obvious bugs. If APC gets on the market 6 months after PHP 5.5 only because of this then we'll be near PHP 5.6 by then. And we can't just change from APC to others as we'll need to test them as well as see which other use data caching like APC has. It would make sense to actually see how the whole ZE can be improved so that it makes life of opcode cachers easier and then ship O+ bundled with a PHP version that has better support for them out of the box if I were to choose. Best regards, Florin ---- Florin Patan https://github.com/dlsniper <http://www.zend.com/en/yellow-pages#show-ClientCandidateID=ZEND013894> On Tue, Jan 29, 2013 at 10:03 AM, Zeev Suraski <zeev@zend.com> wrote:

Ferenc Kovacs

13 years ago
On Tue, Jan 29, 2013 at 11:26 AM, Florin Razvan Patan <florinpatan@gmail.com
> wrote:
> Thank you for this great initiative! > > As a user, I could definitely wait for 2-3 more months and get > a good implementation/integration of this rather that have to > wait for at least one year. > > I think it would also be nice if this could come as default > enabled since this way people would be able to notice the > advantages of having it enabled. Or you can run a survey on > php.net to see what are the options. > > I do have one thing to ask you about this. > > If we do wait 2 months, will the underlaying changes be able > to integrate easy with APC/XCache/eAccelerator/others? > > Opcodes are a must for large traffic websites like those I'm > working on right now, so we clearly want to have such a thing > installed on our servers as soon as we install a new PHP > version. But if including O+ will mean that APC gets delayed > 6+ months (see PHP 5.4) it would be a show stopper for us > upgrading to PHP 5.5. > > Our upgrade process is like this: be at least one year on market > to iron out major/obvious bugs. If APC gets on the market 6 > months after PHP 5.5 only because of this then we'll be near > PHP 5.6 by then. And we can't just change from APC to others > as we'll need to test them as well as see which other use data > caching like APC has. > > It would make sense to actually see how the whole ZE can > be improved so that it makes life of opcode cachers easier > and then ship O+ bundled with a PHP version that has better > support for them out of the box if I were to choose. > > >
please don't top on this list, we prefer bottom or inline posting around here, see http://www.php.net/reST/README.MAILINGLIST_RULES back to the topic: personally I think that even two months seems like a tight schedule as we are talking about incorporating an opcode cache, which I'm pretty sure that it is similar in complexity to apc, and are only like a handful of people on the planet has any experience working with, and needs some polishing and has at least one known shortcoming (thread safety). my opinion is that we should wait for the code to be released before thinking about the release dates.
-- Ferenc Kovács @Tyr43l - http://tyrael.hu

Tyler Sommer

13 years ago
This is really exciting! As a user, I say allow a delay to get this into 5.5. I was kind of disappointed that some cache wasn't bundled with 5.4. It's been too long that this very important piece has been separate from the core. Cheers

Anthony Ferrara

13 years ago
Zeev, First off, very nice job on the RFC. I definitely like what's happening here. As far as delaying 5.5, I have mixed feelings. I think we should definitely consider the delay, but only in a time-boxed format. So if we say "1 month", then if it's not ready to be committed in that month, it doesn't get in and we release 5.5 anyway. I don't think we should do an indefinite (not hard-defined) delay, as we could wind up in a situation similar to 6, where for some reason we wind up delayed for 6 months or worse. I'm not saying I think it'll happen, but we should be careful to limit it. In addition, I would suggest putting in a feature freeze for everything except this feature as well. Not because we shouldn't have new features, but to prevent another "everyone wants this, so let's delay some more" feature 1 week before the timebox expires. Additionally, I don't like the precedent that this sets for future releases. That it's ok to break the timebox for some feature. In this case I think we can justify it, but future cases may use this to justify waiting when it's not completely justified in itself. I'm not sure how we can rectify this concern, but I figured it was worth mentioning. Anthony On Tue, Jan 29, 2013 at 5:37 AM, Tyler Sommer <sommertm@gmail.com> wrote:

Leigh

13 years ago
On 29 January 2013 11:23, Anthony Ferrara <ircmaxell@gmail.com> wrote:
> Zeev, > > First off, very nice job on the RFC. I definitely like what's happening > here. > > As far as delaying 5.5, I have mixed feelings. I think we should definitely > consider the delay, but only in a time-boxed format. So if we say "1 > month", then if it's not ready to be committed in that month, it doesn't > get in and we release 5.5 anyway.
Do you really think a month would be enough (we're talking implementation and really thorough testing)? We're fast approaching beta and the feature freeze, and this is by no means a small feature (correct me if I am mistaken). I think this would very much benefit from the time between releases to get it really thoroughly integrated and tested. Far more eyes will see it, and contribute to it in the time between 5.5 and 5.6 than if it is rushed for 5.5. Stability is king when it comes to adoption, and we really don't need an edge case coming up at the last minute that gives people another reason not to upgrade. In addition, I would suggest putting in a feature freeze for everything
> except this feature as well. Not because we shouldn't have new features, > but to prevent another "everyone wants this, so let's delay some more" > feature 1 week before the timebox expires. >
That would allow more focused testing and development on this specific feature, but...
> Additionally, I don't like the precedent that this sets for future > releases.
.. this. There has already been a couple of discussions this week around "rule bending" (voting / bc breaks). I think the release schedule is an important one to stick to. Is it possible to introduce O+ via PECL in the interim?

Clint M Priest

13 years ago
On 1/29/2013 5:23 AM, Anthony Ferrara wrote:
> Additionally, I don't like the precedent that this sets for future > releases. That it's ok to break the timebox for some feature. In this case > I think we can justify it, but future cases may use this to justify waiting > when it's not completely justified in itself. I'm not sure how we can > rectify this concern, but I figured it was worth mentioning.
I would agree with this sentiment, time boxing from my own personal experience just completely breaks down if you let anything get in the way of it, if you let that box slip for any reason, other reasons become easily justifyable. If 5.5 is due for release, we should not delay it for 2 months to get an opcode cache into core. Additionally: 1) I believe Optimizer+ is the opcode cache that's been discussed but it's not thread safe? 2) Isn't APC the standard? Is it in such bad shape it is not even being considered any longer? 3) There has never been a bundled opcode cache that I'm aware of, one more release without one is not going to surprise many people 4) Waiting for a 5.6 release will give everyone an entire year to get this into core and well tested which based on all the hoopla about how critical APC/opcode caches are to the core it makes sense that integration is going to be a long and painful process.
-- -Clint

Zeev Suraski

13 years ago
> -----Original Message----- > From: Clint Priest [mailto:cpriest@zerocue.com] > Sent: Tuesday, January 29, 2013 3:30 PM > To: Anthony Ferrara > Cc: Tyler Sommer; Zeev Suraski; internals@lists.php.net > Subject: Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP > distribution > > On 1/29/2013 5:23 AM, Anthony Ferrara wrote: > > Additionally, I don't like the precedent that this sets for future > > releases. That it's ok to break the timebox for some feature. In this > > case I think we can justify it, but future cases may use this to > > justify waiting when it's not completely justified in itself. I'm not > > sure how we can rectify this concern, but I figured it was worth
mentioning.
> I would agree with this sentiment, time boxing from my own personal > experience just completely breaks down if you let anything get in the
way of it, if
> you let that box slip for any reason, other reasons become easily
justifyable. If
> 5.5 is due for release, we should not delay it for 2 months to get an
opcode
> cache into core. > > Additionally: > > 1) I believe Optimizer+ is the opcode cache that's been discussed but
it's not
> thread safe?
It's presently not thread safe. Just to be sure we're all on the same page, this is only meaningful if you're running PHP on Windows and not using FastCGI; It's completely meaningless in any other scenario (i.e. for the vast majority of users); That said, adding thread safety support for Optimizer+ is a fairly easy task. We've never done it because none of our commercial products use thread-safe PHP. I'll update the RFC to clarify the scope of this limitation.
> 2) Isn't APC the standard? Is it in such bad shape it is not even being
considered
> any longer?
Did you read the RFC? Yes, it is considered, and it's certainly an option on the table, with advantages and disadvantages. There's a whole section in the RFC about it.
> 3) There has never been a bundled opcode cache that I'm aware of, one
more
> release without one is not going to surprise many people > > 4) Waiting for a 5.6 release will give everyone an entire year to get
this into core
> and well tested which based on all the hoopla about how critical
APC/opcode
> caches are to the core it makes sense that integration is going to be a
long and
> painful process.
I for one am not very fond of having a release every 12 months, and the current pace of every 18 month seems rapid enough. So we'd be talking about a year and a half, not a year. My opinion is that looking at our adoption patterns, delaying by 2 months and providing an opcode cache right off the bat would be much preferable to the vast majority of users. People are barely using 5.4 today - it would hardly make a difference if we release 5.5 two months earlier or two months later. But that too would be up for discussion and voting. Zeev

Derick Rethans

13 years ago
On Tue, 29 Jan 2013, Zeev Suraski wrote:
> From: Clint Priest [mailto:cpriest@zerocue.com]: > > > On 1/29/2013 5:23 AM, Anthony Ferrara wrote: > > > > > Additionally, I don't like the precedent that this sets for future > > > releases. That it's ok to break the timebox for some feature. In > > > this case I think we can justify it, but future cases may use this > > > to justify waiting when it's not completely justified in itself. > > > I'm not sure how we can rectify this concern, but I figured it was > > > worth mentioning. > > > > I would agree with this sentiment, time boxing from my own personal > > experience just completely breaks down if you let anything get in > > the way of it, if you let that box slip for any reason, other > > reasons become easily justifyable. If 5.5 is due for release, we > > should not delay it for 2 months to get an opcode cache into core. > > > > Additionally: > > > > 1) I believe Optimizer+ is the opcode cache that's been discussed > > but it's not thread safe? > > It's presently not thread safe. Just to be sure we're all on the same > page, this is only meaningful if you're running PHP on Windows and not > using FastCGI; It's completely meaningless in any other scenario (i.e. > for the vast majority of users); That said, adding thread safety support > for Optimizer+ is a fairly easy task. We've never done it because none of > our commercial products use thread-safe PHP. I'll update the RFC to > clarify the scope of this limitation.
I wouldn't bother making it work with ZTS. If you want performance, you shouldn't be using it, and the other case I heard was "pthreads" in which case it plays no role,as all of the script is in memory anyway for the duration of the process. cheers, Derick
-- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine

Bob Weinand

13 years ago
Am 29.1.2013 um 15:58 schrieb Derick Rethans <derick@php.net>:
> I wouldn't bother making it work with ZTS. If you want performance, you > shouldn't be using it, and the other case I heard was "pthreads" in > which case it plays no role,as all of the script is in memory anyway > for the duration of the process. > > cheers, > Derick > > -- > http://derickrethans.nl | http://xdebug.org > Like Xdebug? Consider a donation: http://xdebug.org/donate.php > twitter: @derickr and @xdebug > Posted with an email client that doesn't mangle email: alpine > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Hi, you want to say someone who wants to use pthreads, should have to maintain two different installations of php, one with zts for the daemon and one without for the apache? Having to maintain only one installation makes life really easier... regards, Bob

Derick Rethans

13 years ago
On Tue, 29 Jan 2013, Bob Weinand wrote:
> Am 29.1.2013 um 15:58 schrieb Derick Rethans <derick@php.net>: > > > I wouldn't bother making it work with ZTS. If you want performance, > > you shouldn't be using it, and the other case I heard was "pthreads" > > in which case it plays no role,as all of the script is in memory > > anyway for the duration of the process. > > you want to say someone who wants to use pthreads, should have to > maintain two different installations of php, one with zts for the > daemon and one without for the apache? Having to maintain only one > installation makes life really easier...
Really? I have like 20 of them. Hardly a sweat. This includes 5.1->5.5, zts and even 32bit builds. I suggest you educate yourself on installing - and as a hint: http://derickrethans.nl/multiple-php-version-setup.html cheers, Derick
-- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine

Rasmus Lerdorf

13 years ago
On 01/29/2013 05:30 AM, Clint Priest wrote:
> 2) Isn't APC the standard? Is it in such bad shape it is not even being > considered any longer?
As it currently stands from a developer participation standpoint it is not viable. I outlined the issues in a previous post. You also have to take into account that most sites can't actually move to the next release of PHP until APC is stable with it. So effectively the PHP 5.4 release didn't happen until APC 3.1.13 in September 2012 which was a full 6 months after PHP 5.4.0. I don't foresee this getting any better for PHP 5.5. In order for PHP releases to actually mean something this is a problem we have to fix. I honestly don't care which opcode cache implementation we base a core version on, what I care about is developer buy-in. Dmitry and Stas being familiar with the code already outnumbers the number of active core devs working on APC today. I understand some of the skepticism and hurt feelings around this from a few old-timers, but let's move on and see if we can finally push out a release with solid opcode caching right at the release date. From my perspective anything up to a 6-month delay would beat the current situation. -Rasmus

Nikita Popov

13 years ago
On Tue, Jan 29, 2013 at 2:52 PM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:
> On 01/29/2013 05:30 AM, Clint Priest wrote: > > > 2) Isn't APC the standard? Is it in such bad shape it is not even being > > considered any longer? > > As it currently stands from a developer participation standpoint it is > not viable. I outlined the issues in a previous post. > > You also have to take into account that most sites can't actually move > to the next release of PHP until APC is stable with it. So effectively > the PHP 5.4 release didn't happen until APC 3.1.13 in September 2012 > which was a full 6 months after PHP 5.4.0. I don't foresee this getting > any better for PHP 5.5. > > In order for PHP releases to actually mean something this is a problem > we have to fix. I honestly don't care which opcode cache implementation > we base a core version on, what I care about is developer buy-in. Dmitry > and Stas being familiar with the code already outnumbers the number of > active core devs working on APC today. > > I understand some of the skepticism and hurt feelings around this from a > few old-timers, but let's move on and see if we can finally push out a > release with solid opcode caching right at the release date. From my > perspective anything up to a 6-month delay would beat the current > situation. >
I'm not sure I fully understand this. The RFC claims that Optimizer+ is already *now* fully compatible with PHP 5.5. And that it was also compatible when PHP 5.4 was released. So they lack of a working and free opcode cache clearly wasn't the issue. My guess is rather that the lack of APC support (as in specifically APC and not just some opcode cache) was an issue. Either because people didn't know about alternatives (APC after all is the go-to opcode cache), didn't want to try them or had software tightly integrated with APC (and in particular its user cache). Just to be clear: I fully agree that PHP needs a working opcode cache when PHP 5.5 ships, otherwise adoption will be like 5.4. But I'm not sure what exactly changes between Optimizer+ being in core (enable via configure) and Optimizer+ being in PECL (enable via install). The main point I always saw behind including APC in core is that it would require core developers to maintain it and to update it when doing ZE changes, on their own. This doesn't seem to be a motivation for Optimizer+. Apart from that I see rather little difference between core/pecl. Opcode caching is the kind of thing where the "if it's in pecl nobody will use it" logic does not apply, as people using opcode caches run their own servers. I do get that opcode caching is commonly needed, so it would be nice to have it in core (easier installation?), but I don't see why we should put off the release for one, two, or more months, for that small convenience. Thanks, Nikita

Rasmus Lerdorf

13 years ago
On 01/29/2013 06:13 AM, Nikita Popov wrote:
> I'm not sure I fully understand this. The RFC claims that Optimizer+ is > already *now* fully compatible with PHP 5.5. And that it was also > compatible when PHP 5.4 was released. So they lack of a working and free > opcode cache clearly wasn't the issue. My guess is rather that the lack > of APC support (as in specifically APC and not just some opcode cache) > was an issue. Either because people didn't know about alternatives (APC > after all is the go-to opcode cache), didn't want to try them or had > software tightly integrated with APC (and in particular its user cache).
Closed source isn't an option for many sites.

Lars Strojny

13 years ago
Hi Zeev, Am 29.01.2013 um 15:21 schrieb Rasmus Lerdorf <rasmus@lerdorf.com>:
> On 01/29/2013 06:13 AM, Nikita Popov wrote: > >> I'm not sure I fully understand this. The RFC claims that Optimizer+ is >> already *now* fully compatible with PHP 5.5. And that it was also >> compatible when PHP 5.4 was released. So they lack of a working and free >> opcode cache clearly wasn't the issue. My guess is rather that the lack >> of APC support (as in specifically APC and not just some opcode cache) >> was an issue. Either because people didn't know about alternatives (APC >> after all is the go-to opcode cache), didn't want to try them or had >> software tightly integrated with APC (and in particular its user cache).
[...] I personally find it quite cool, that Zend considers open sourcing its Optimizer+ product. I’m obviously just guessing, but I am halfway sure, that APC (and XCache etc.) have a lot to do with Zend being willing to do that move. In a sense that it helped making opcode caches a commodity. Maybe that’s a small solace for the countless hours that where spent on APC. To get more practical, I see the following steps going forward: 1.) Zend releases a first open sourced version of Optimizer+ on PECL (or somewhere else) 2.) We as a community can have a look at the code 3.) We vote on the RFC 3a.) Question a) Should Optimizer+ be included in core: yes/no 3b.) Question b) If yes, may the inclusion delay 5.5 by X month: yes/no 4.) The proposers make sure it works with ZTS as well (this obviously doesn’t exclude help from outside contributors) @Zeev, out of interest, how much time does Zend plan to spend on maintaining Optimizer+ in the core for the foreseeable future? cu, Lars

Zeev Suraski

13 years ago
> -----Original Message----- > From: Lars Strojny [mailto:lars@strojny.net] > Sent: Tuesday, January 29, 2013 4:33 PM > To: Rasmus Lerdorf > Cc: Nikita Popov; internals@lists.php.net > Subject: Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP > distribution
>To get more practical, I see the > following steps going forward: > > 1.) Zend releases a first open sourced version of Optimizer+ on PECL
(or
> somewhere else) > 2.) We as a community can have a look at the code > 3.) We vote on the RFC > 3a.) Question a) Should Optimizer+ be included in core: yes/no > 3b.) Question b) If yes, may the inclusion delay 5.5 by X month: yes/no > 4.) The proposers make sure it works with ZTS as well (this obviously
doesn't
> exclude help from outside contributors)
This is roughly the roadmap we have in mind. Given that some people are eager not to delay 5.5.0 either at all or more than we absolutely have to, I figured I'd parallelize the discussion and the work we're doing to prep it for open sourcing. We're already well under way into that process, and I'm hopeful we can publish it within a week or so. BTW, Dmitry already baked ZTS support in earlier today. I said it shouldn't take too long :)
> @Zeev, out of interest, how much time does Zend plan to spend on
maintaining
> Optimizer+ in the core for the foreseeable future?
We view it as an essential part of the PHP stack so we'll maintain it in the same manner we help maintain the Zend Engine. Zeev

Nikita Popov

13 years ago
On Tue, Jan 29, 2013 at 3:21 PM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:
> On 01/29/2013 06:13 AM, Nikita Popov wrote: > > > I'm not sure I fully understand this. The RFC claims that Optimizer+ is > > already *now* fully compatible with PHP 5.5. And that it was also > > compatible when PHP 5.4 was released. So they lack of a working and free > > opcode cache clearly wasn't the issue. My guess is rather that the lack > > of APC support (as in specifically APC and not just some opcode cache) > > was an issue. Either because people didn't know about alternatives (APC > > after all is the go-to opcode cache), didn't want to try them or had > > software tightly integrated with APC (and in particular its user cache). > > Closed source isn't an option for many sites. >
So then this is a solved issue, right? Zend will open source Optimizer+ (very cool!). Everyone gets a working opcode cache (win), the release is not delayed (win). For 5.6 it can be included into the distribution (a bit more win). Nikita :)

Kalle Sommer Nielsen

13 years ago
Hi Zeev 2013/1/29 Zeev Suraski <zeev@zend.com>:
> In parallel we’re in the process of prepping the source code for > independent public consumption, which I hope we can be done with by the end > of next week, hopefully sooner.
I'm sorry, but I don't see why we out of a sudden should consider adding a Zend product to the core, over that we got already, yes I'm pointing in APC's direction, although it is in PECL. I'm not trying to bring in this skepticism here because I'm, a previous APC dev, but mostly because I do not think this is the right move. Why? Because we tried to push APC from PECL into the Core since early 5.x, although I've only been around since just before 5.3a1, I remember how we were all focused on putting APC into the Core rather than a non php.net project (like XCache, eAccelerator, ...), where many of the core developers have invested much time in promoting APC, and tried to fix some of the issues it have had. Moving APC into the core was against some people's PoV because they thought it would be enabled by default, which it wouldn't be at all. I am very strongly against this move if its approved (not the actual RFC), but how an outside product suddenly deserves a spot in the core over our own code, by that I mean folks that does not work for Zend, but have contributed the code to php.net, I think that is highly controversial.
-- regards, Kalle Sommer Nielsen kalle@php.net

Pierre Joye

13 years ago
On Tue, Jan 29, 2013 at 2:27 PM, Kalle Sommer Nielsen <kalle@php.net> wrote:
> Hi Zeev > > 2013/1/29 Zeev Suraski <zeev@zend.com>: >> In parallel we’re in the process of prepping the source code for >> independent public consumption, which I hope we can be done with by the end >> of next week, hopefully sooner. > > I'm sorry, but I don't see why we out of a sudden should consider > adding a Zend product to the core, over that we got already, yes I'm > pointing in APC's direction, although it is in PECL.
> I'm not trying to bring in this skepticism here because I'm, a > previous APC dev, but mostly because I do not think this is the right > move. Why? Because we tried to push APC from PECL into the Core since > early 5.x,
It is not done yet. But given that the code is clean and easily maintainable, it could be much more efficient for us to focus on one extension and make it rock instead of trying to get each of them work well. As Rasmus stated, between the opcode/engine and the way such extensions work, we only have a handful of developers able to work on them, and not full time. Cheers,
-- Pierre @pierrejoye

Kalle Sommer Nielsen

13 years ago
Hi Pierre 2013/1/29 Pierre Joye <pierre.php@gmail.com>:
> It is not done yet. But given that the code is clean and easily > maintainable, it could be much more efficient for us to focus on one > extension and make it rock instead of trying to get each of them work > well. As Rasmus stated, between the opcode/engine and the way such > extensions work, we only have a handful of developers able to work on > them, and not full time.
I totally agree that having one extension and making it work altogether is better, but the way I see it presented is that Zend wants to lends us a hand if we pick their product, FOSS it and put it into the core, so we got some more people working on it (I won't say full time), but I'm sure that if its a Zend product there are gonna be some more attention to it from their side.
-- regards, Kalle Sommer Nielsen kalle@php.net

Zeev Suraski

13 years ago
> -----Original Message----- > From: kalle.php@gmail.com [mailto:kalle.php@gmail.com] On Behalf Of
Kalle
> Sommer Nielsen > Sent: Tuesday, January 29, 2013 3:28 PM > To: Zeev Suraski > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP > distribution > > Hi Zeev > > 2013/1/29 Zeev Suraski <zeev@zend.com>: > > In parallel we're in the process of prepping the source code for > > independent public consumption, which I hope we can be done with by > > the end of next week, hopefully sooner. > > I'm sorry, but I don't see why we out of a sudden should consider adding
a Zend
> product to the core, over that we got already, yes I'm pointing in APC's > direction, although it is in PECL.
The RFC explains the pros and cons of doing that, I don't really have any additional reasons to add beyond what I already put there. I believe the pros outweigh the cons by a good considerable margin, but that's what the vote would be about. Perhaps the one thing worth adding is that the people who worked on Optimizer+ are all major php.net contributors, including Dmitry, Stas, Andi and myself - it's not some alien artifact. Zeev

Kalle Sommer Nielsen

13 years ago
2013/1/29 Zeev Suraski <zeev@zend.com>:
> The RFC explains the pros and cons of doing that, I don't really have any > additional reasons to add beyond what I already put there. I believe the > pros outweigh the cons by a good considerable margin, but that's what the > vote would be about. Perhaps the one thing worth adding is that the > people who worked on Optimizer+ are all major php.net contributors, > including Dmitry, Stas, Andi and myself - it's not some alien artifact.
I don't doubt any of your abilities, what I do doubt is that how we can consider an outside project directly into the core. APC would without a doubt be up to pair if there was more people willingly to dwell into it (yes dwell as many people see it as an alien artifact because it touches and modifies some "unusual" things that the average extension developer don't).
-- regards, Kalle Sommer Nielsen kalle@php.net

Zeev Suraski

13 years ago
> -----Original Message----- > From: kalle.php@gmail.com [mailto:kalle.php@gmail.com] On Behalf Of
Kalle
> Sommer Nielsen > Sent: Tuesday, January 29, 2013 3:45 PM > To: Zeev Suraski > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP > distribution > > 2013/1/29 Zeev Suraski <zeev@zend.com>: > > The RFC explains the pros and cons of doing that, I don't really have > > any additional reasons to add beyond what I already put there. I > > believe the pros outweigh the cons by a good considerable margin, but > > that's what the vote would be about. Perhaps the one thing worth > > adding is that the people who worked on Optimizer+ are all major > > php.net contributors, including Dmitry, Stas, Andi and myself - it's
not some
> alien artifact. > > I don't doubt any of your abilities, what I do doubt is that how we can
consider
> an outside project directly into the core. APC would without a doubt be
up to
> pair if there was more people willingly to dwell into it (yes dwell as
many people
> see it as an alien artifact because it touches and modifies some
"unusual" things
> that the average extension developer don't).
I wasn't talking about our abilities, but about our 'outsideness'. Yes, it is/was a closed source component, but it's by the same people that have written a huge deal of PHP's scripting engine. I'd would of course prefer that we evaluate the proposal based on the substance and not on other factors, but that said, I fully respect your position and wouldn't hold it against you if you vote 'no'... Zeev

Kalle Sommer Nielsen

13 years ago
2013/1/29 Zeev Suraski <zeev@zend.com>:
> I'd would of course prefer that we evaluate the proposal based on the > substance and not on other factors, but that said, I fully respect your > position and wouldn't hold it against you if you vote 'no'...
My vote will ofcourse also take the RFC into consideration, else it would be a pointless vote, if it was an addition to PECL my vote would be a direct yes however, but directly into the core, no. As Nikita said in the previous post, we really need an opcode cacher in 5.5, but I still have a hard time seeing the justification of this, although its written by some of the longest time contributors in PHP's history.
-- regards, Kalle Sommer Nielsen kalle@php.net

Lester Caine

13 years ago
Kalle Sommer Nielsen wrote:
> 2013/1/29 Zeev Suraski<zeev@zend.com>: >> >The RFC explains the pros and cons of doing that, I don't really have any >> >additional reasons to add beyond what I already put there. I believe the >> >pros outweigh the cons by a good considerable margin, but that's what the >> >vote would be about. Perhaps the one thing worth adding is that the >> >people who worked on Optimizer+ are all major php.net contributors, >> >including Dmitry, Stas, Andi and myself - it's not some alien artifact. > I don't doubt any of your abilities, what I do doubt is that how we > can consider an outside project directly into the core. APC would > without a doubt be up to pair if there was more people willingly to > dwell into it (yes dwell as many people see it as an alien artifact > because it touches and modifies some "unusual" things that the average > extension developer don't).
A fresh injection of 'blood' may do wonders? Since there are other options to APC which may be alternative candidates, on one hand it makes perfect sense that such a knowledgeable clean sheet is at least considered especially since the code is almost feature complete? But providing it as another external (PECL) option initially makes more sense? If only to allow comparison with APC, eaccelerator and the rest? I'll get my head chewed off again, but can we no consider doing that as PHP6 given that 6.0.x could be a development stage. I would perhaps then strongly lobby for 'only' having E_STRICT mode so things like 'static $this' go by the by anyway? This would not rule out a 5.5 with just the current suit of extras although personally I'd prefer a longer maintained 5.4 with just the extras that dovetail well included.
-- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Kalle Sommer Nielsen

13 years ago
2013/1/29 Lester Caine <lester@lsces.co.uk>:
> I'll get my head chewed off again, but can we no consider doing that as PHP6 > given that 6.0.x could be a development stage. I would perhaps then strongly > lobby for 'only' having E_STRICT mode so things like 'static $this' go by > the by anyway? This would not rule out a 5.5 with just the current suit of > extras although personally I'd prefer a longer maintained 5.4 with just the > extras that dovetail well included.
What is 'static $this', and how does E_STRICT belong to this whole discussion?
-- regards, Kalle Sommer Nielsen kalle@php.net

Lester Caine

13 years ago
Kalle Sommer Nielsen wrote:
> 2013/1/29 Lester Caine <lester@lsces.co.uk>: >> I'll get my head chewed off again, but can we no consider doing that as PHP6 >> given that 6.0.x could be a development stage. I would perhaps then strongly >> lobby for 'only' having E_STRICT mode so things like 'static $this' go by >> the by anyway? This would not rule out a 5.5 with just the current suit of >> extras although personally I'd prefer a longer maintained 5.4 with just the >> extras that dovetail well included. > > What is 'static $this', and how does E_STRICT belong to this whole discussion?
[VOTE] Deprecate and remove calls from incompatible context This is another area where a major overhaul needs a major version number shift. Just looking at this as an overview of where we ideally want to be quicker than going through 5.5/5.6 releases would allow. Alright the optimizer could simply remain an extra that anybody can use now, but planning a streamlined PHP6 release which 'ZTS', 'mysql' and the like could be formally sorted out?
-- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Stas Malyshev

13 years ago
Hi!
> I don't doubt any of your abilities, what I do doubt is that how we > can consider an outside project directly into the core. APC would
How it's more "outside product" than any of the other extensions we brought to the core?
> without a doubt be up to pair if there was more people willingly to > dwell into it (yes dwell as many people see it as an alien artifact
If.
-- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227

Kalle Sommer Nielsen

13 years ago
Hi 2013/1/30 Stas Malyshev <smalyshev@sugarcrm.com>:
> How it's more "outside product" than any of the other extensions we > brought to the core?
Because it was not developed at php.net for example? How many extensions thats in the core today was not developed somewhere at php.net, or was either in PECL first? What I'm saying is that I think it should go to PECL first before getting adapted into the core, no matter who or where it was developed from if it was not developed here, yes I realize I make it sound like an alien artifact as Zeev said. What if the guys at XCache asked for it to be added to the main distribution, I'm pretty sure that most would say let it to go PECL or compare it with APC and have a race there, but the fact that it is (with all respect) guys who worked heavily on the Engine seems to blind some people, which is what I'm against.
-- regards, Kalle Sommer Nielsen kalle@php.net

Steve Clay

13 years ago
On 1/30/13 8:36 AM, Kalle Sommer Nielsen wrote:
> What if the guys at XCache asked for it to be added to the main > distribution, I'm pretty sure that most would say let it to go PECL or
Isn't the important thing whether it survives the RFC/voting process? If devs agree with you that time served in PECL is essential, they can vote it down. If XCache would be better, someone could submit an RFC... Steve Clay
-- http://www.mrclay.org/

Stas Malyshev

13 years ago
Hi!
> Because it was not developed at php.net for example? How many
I'm not sure what is the meaning here. Nothing is developed "at php.net", strictly speaking. php.net doesn't have its own development team that works exclusively for php.net, it just gets code contributions from volunteers. And many people working right now on PHP have their salaries paid by major companies, like IBM, Microsoft, Oracle, Facebook and so on. Some of them are paid specifically for doing PHP-related stuff, AFAIK. We had a number of extensions which development was initiated and/or sponsored by various companies. Could you explain what "developed at php.net" really means? If I develop some extension on my laptop and then commit it to git - is is "developed at php.net" or not?
> extensions thats in the core today was not developed somewhere at > php.net, or was either in PECL first? What I'm saying is that I think > it should go to PECL first before getting adapted into the core, no > matter who or where it was developed from if it was not developed > here, yes I realize I make it sound like an alien artifact as Zeev > said.
If the problem is that it wasn't in PECL - the RFC says "As the code becomes available, put it in PECL.". Once that happens, we can discuss moving it to core - as an extension - should be in 5.5 or later. PECL is not going away and is the first step anyway. It seems like what you're saying is that it should be in PECL at least for a year before it can be merged (please correct me if I'm wrong here). Now, I can see how it could be for an extension whose usage and stability is uncertain - we don't know yet if a parser for foobar protocol is needed or if it actually works, so let's put it in PECL and wait and see. However, here we know it (bytecode caching) is needed and this extension has been worked on for many years. Still, if you have concerns about it - it will be placed in PECL, you could see it and then make your judgement about schedule and such.
-- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227

Derick Rethans

13 years ago
On Tue, 29 Jan 2013, Zeev Suraski wrote:
> Following the discussion at the end of last week, I prepared a draft > RFC for the inclusion of Optimizer+ in PHP. > > In parallel we’re in the process of prepping the source code for > independent public consumption, which I hope we can be done with by > the end of next week, hopefully sooner. > > https://wiki.php.net/rfc/optimizerplus > > Comments welcome!
I like it. It would be totally awesome if it came with a webinar or something where Dmitry/Stas explain how it works though. Understanding how APC works has always been a contentious point. I'd be awesome if we could turn that around with O+? cheers, Derick

Sebastian Bergmann

13 years ago
Am 29.01.2013 16:54, schrieb Derick Rethans:
> I like it. It would be totally awesome if it came with a webinar or > something where Dmitry/Stas explain how it works though. Understanding > how APC works has always been a contentious point. I'd be awesome if we > could turn that around with O+?
I think it is a good thing that Zend open sources their bytecode cache. And I think that what Derick proposes is a brilliant idea.
-- Sebastian Bergmann Co-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/

Zeev Suraski

13 years ago
On 29 בינו 2013, at 17:54, Derick Rethans <derick@php.net> wrote:
> On Tue, 29 Jan 2013, Zeev Suraski wrote: > >> Following the discussion at the end of last week, I prepared a draft >> RFC for the inclusion of Optimizer+ in PHP. >> >> In parallel we’re in the process of prepping the source code for >> independent public consumption, which I hope we can be done with by >> the end of next week, hopefully sooner. >> >> https://wiki.php.net/rfc/optimizerplus >> >> Comments welcome! > > I like it. It would be totally awesome if it came with a webinar or > something where Dmitry/Stas explain how it works though. Understanding > how APC works has always been a contentious point. I'd be awesome if we > could turn that around with O+? >
I'm sure we can arrange that. Zeev

Pierre Joye

13 years ago
On Tue, Jan 29, 2013 at 5:54 PM, Zeev Suraski <zeev@zend.com> wrote:
> On 29 בינו 2013, at 17:54, Derick Rethans <derick@php.net> wrote: > >> On Tue, 29 Jan 2013, Zeev Suraski wrote: >> >>> Following the discussion at the end of last week, I prepared a draft >>> RFC for the inclusion of Optimizer+ in PHP. >>> >>> In parallel we’re in the process of prepping the source code for >>> independent public consumption, which I hope we can be done with by >>> the end of next week, hopefully sooner. >>> >>> https://wiki.php.net/rfc/optimizerplus >>> >>> Comments welcome! >> >> I like it. It would be totally awesome if it came with a webinar or >> something where Dmitry/Stas explain how it works though. Understanding >> how APC works has always been a contentious point. I'd be awesome if we >> could turn that around with O+? >> > > I'm sure we can arrange that.
Well, a webinar is nice and shiny but I would rather see them spend time on writing a very good documentation instead. Much more useful and can be updated easily. Cheers,
-- Pierre @pierrejoye

Camilo Sperberg

13 years ago
Sent from my iPhone 6 Beta [Confidential use only] On 29 jan. 2013, at 18:02, Pierre Joye <pierre.php@gmail.com> wrote:
> On Tue, Jan 29, 2013 at 5:54 PM, Zeev Suraski <zeev@zend.com> wrote: >> On 29 בינו 2013, at 17:54, Derick Rethans <derick@php.net> wrote: >> >>> On Tue, 29 Jan 2013, Zeev Suraski wrote: >>> >>>> Following the discussion at the end of last week, I prepared a draft >>>> RFC for the inclusion of Optimizer+ in PHP. >>>> >>>> In parallel we’re in the process of prepping the source code for >>>> independent public consumption, which I hope we can be done with by >>>> the end of next week, hopefully sooner. >>>> >>>> https://wiki.php.net/rfc/optimizerplus >>>> >>>> Comments welcome! >>> >>> I like it. It would be totally awesome if it came with a webinar or >>> something where Dmitry/Stas explain how it works though. Understanding >>> how APC works has always been a contentious point. I'd be awesome if we >>> could turn that around with O+? >> >> I'm sure we can arrange that. > > Well, a webinar is nice and shiny but I would rather see them spend > time on writing a very good documentation instead. Much more useful > and can be updated easily. > > > Cheers, > -- > Pierre > > @pierrejoye > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
As just a normal user without any voting rights, I recognize that integrating O+ would be a major improvement for PHP and should be incorporated in core as soon as possible. If it only takes 2 months, go for it, userland cache would be really awesome to have but an opcode cache in core is far better. APC is already very difficult to manage and integrate (6+ months), so why not integrate O+ in the first place and in the next PHP release an userland cache space? It could be a simplified and easier-to-maintain APC version and it would help to keep everything as modular as possible. Greetings.

Stas Malyshev

13 years ago
Hi!
> I like it. It would be totally awesome if it came with a webinar or > something where Dmitry/Stas explain how it works though. Understanding > how APC works has always been a contentious point. I'd be awesome if we > could turn that around with O+?
Once the code is out there, I think it's definitely possible.
-- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227

David Soria Parra

13 years ago
On 2013-01-29, Zeev Suraski <zeev@zend.com> wrote:
> --e89a8fb1f5b0f501b204d468d53f > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: quoted-printable > > All, > > > > Following the discussion at the end of last week, I prepared a draft RFC > for the inclusion of Optimizer+ in PHP. > > In parallel we=E2=80=99re in the process of prepping the source code for > independent public consumption, which I hope we can be done with by the end > of next week, hopefully sooner. > > > > https://wiki.php.net/rfc/optimizerplus > > > > Comments welcome!
As already said in this thread, the major issue for 5.4 adaption was APC, so I really like that we get a 5.5 compatible optimizer. We are planning to go into beta mode next week which is a feature freeze. Therefore optimizer would not make it in, but I think as the code is already mature and not just a random new feature I think we can allow this into core during beta phase, maybe for 5.5 disabled by default. Anyhow we are already late with 5.5.0 and I dont want a 5.5.0 release in May. David

Terry Ellison

13 years ago

Terry Ellison

13 years ago
On 29/01/13 08:03, Zeev Suraski wrote:
> Following the discussion at the end of last week, I prepared a draft RFC > for the inclusion of Optimizer+ in PHP. > > In parallel we’re in the process of prepping the source code for > independent public consumption, which I hope we can be done with by the end > of next week, hopefully sooner.
It's great news that Zend Technologies has decided to open-source Optimizer+ and given that it is now "the end of next week I look forward to seeing on this code any day. So thanks to you for this decision. But now to specific comments on your RFC. 1. Scope of the RFC. IMO, the RFC covers four separate issues that would be easier to review, refine and agree if they were kept separate: a. Zend's decision to OS+. This is entirely within Zend Technology Inc. and outside the scope of any RFC. b. The establishment and proper architecture and support of an opcode-cache interface within the Zend Execution Engine (EE). I will discuss this below. c. The decision to include Optimizer+ as a core extension within the PHP project. However as at the time of this draft only Zend employees -- and selected Zend-approved 2nd parties who have signed the appropriate NDAs -- have access to the Optimizer+ source and are therefore able to review its content. Surely such open access is a precondition, and it makes no sense to issue an RFC to inform this decision until at least a few months after the source has been made widely available for review. d. The project decision to give any specific opcode-cache extension a "preferred" status over the alternative opcode-caches. Such a decision is going to be contentious and -- unless carefully, transparently and fairly managed -- could lead to conflict within the project. Not good. So I would suggest that the RFC limit itself to non-contentious claims relating to one optimizer performance over another. 2. The Detailed Content The Introduction will need redrafting depending on the proposed / revised scope of this RFC. Some form of definition / description of both a PHP opcode-cache and PHP data-cache needs including in the PHP wiki, but this would sit better under the https://wiki.php.net/internals hierarchy. This RFC should simply wiki-link to this page on the first use of [[opcode cache]]. The "Interaction with other extensions and plugins" section is surely a general statement of requirement that should apply to _any_ opcode cache and not just Optmizer+, so again this content belongs in separate Wiki a document with a wiki-link here. The "Alternatives" is really a "Comparison of APC and Optimizer+" and I suggest that some points are contentious. The same point applies to the remaining sections. Surely this sort of comparison only becomes necessary when we've reach a stage where we are asking voters to choose a preferred cache, and in that case wouldn't be more appropriate to agree the selection / assessment criteria first before carrying out a selection exercise? 3. Why do I suggest an Opcode-Cache interface RFC? The current Zend 2.x engines provide some hooks which enable the main opcode caches -- including Optimizer+ and APC -- to deliver accelerated performance for many application usecases. However, some aspects of hooking an opcode cache into the Zend EE remain a somewhat of a compromise. These include: a. The management of early vs. late binding and the work-arounds that opcode caches must do to back-out unwanted early binding. b. Some essential functions that the caches must hook into are not exposed as hooks (like zend_compile_file) and are sometime implemented using static functions, leading to the cache needing to reimplement chunks of zend code. c. There should be a clear scoping separation of what the (cached) compile does and what the EE does. An example of where this is mixed is in the ZEND_INCLUDE_OR_EVAL_xxx_HANDLER functions which resolve paths and open source files in the case of the xxx_once functions. This file access is usually unnecessary in the case of cached files as the op-code cache has already cached the relevant information. Given that opcode caches are now core to PHP performance, it should be possible to implement a cache using hooks and interfaces exported through a Zend header file and without recoding bits of the engine. Optimizer+ should be an exemplar of such an approach. Regards Terry Ellison

Pierre Joye

13 years ago
hi Zeev, On Tue, Jan 29, 2013 at 9:03 AM, Zeev Suraski <zeev@zend.com> wrote: Any news on this front? It's becoming harder and harder to consider it in 5.5 if we have to wait longer. There are enough volunteers to help, open it now :) Cheers, Pierre

Zeev Suraski

13 years ago
We're trying to do exactly that. It's taking a bit longer than expected but I'm hopeful we'll open the initial code base tomorrow. Zeev
> -----Original Message----- > From: Pierre Joye [mailto:pierre.php@gmail.com] > Sent: Tuesday, February 12, 2013 3:48 PM > To: Zeev Suraski > Cc: PHP internals > Subject: Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP > distribution > > hi Zeev, > > On Tue, Jan 29, 2013 at 9:03 AM, Zeev Suraski <zeev@zend.com> wrote: > > Any news on this front? > > It's becoming harder and harder to consider it in 5.5 if we have to wait
longer.

Thomas Bley

13 years ago
On Tue, Feb 12, 2013 at 5:20 PM, Zeev Suraski <zeev@zend.com> wrote:
> We're trying to do exactly that. It's taking a bit longer than expected > but I'm hopeful we'll open the initial code base tomorrow. > > Zeev > >> -----Original Message----- >> From: Pierre Joye [mailto:pierre.php@gmail.com] >> Sent: Tuesday, February 12, 2013 3:48 PM >> To: Zeev Suraski >> Cc: PHP internals >> Subject: Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP >> distribution >> >> hi Zeev, >> >> On Tue, Jan 29, 2013 at 9:03 AM, Zeev Suraski <zeev@zend.com> wrote: >> >> Any news on this front? >> >> It's becoming harder and harder to consider it in 5.5 if we have to wait > longer. >> There are enough volunteers to help, open it now :) >> >> Cheers, >> Pierre > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
My weekend is reserved for testing! Regards, Thomas