Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
On Tue, Feb 12, 2013 at 5:20 PM, Zeev Suraski z...@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@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 z...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
hi Zeev, On Tue, Jan 29, 2013 at 9:03 AM, Zeev Suraski z...@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
RE: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
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@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 z...@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
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
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.
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
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
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
- Ursprüngliche Message - Von: Zeev Suraski z...@zend.com An: hakre hanskren...@yahoo.de CC: internals@lists.php.net Gesendet: 15:31 Dienstag, 5.Februar 2013 Betreff: RE: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution Based on an 18 month release cycle, and assuming we release 5.5.0 in mid 2013, 5.6.0 will come out late 2014. I wonder where you pick those quantifications from, according to https://wiki.php.net/rfc/releaseprocess there is 12 month cycle/tact, and according to the release date of PHP 5.4 major releases (golden) are scheduled for the first of march each year (alphas accordingly earlier). I'm taking it from both reality and the discussions we had surrounding the release process RFC (in short, the 'yearly' in there was subject to change without notice; It's not an 11th commandment). I see good reasons not to go with a yearly release cycle, considering there's next to nobody actually interested in consuming those releases, but that's another story. Well in/for reality I only care about the documentation. If the RFC has no use to communicate a qualified decision, this should be clearly written down somewhere if that is a common good. Also I have problems to decipher the 11th commandment - Thou shalt not speak ill of any fellow Republican. ??? And as you talk about it: do you know if there was criticism with the yearly release cycle before the new release process? I can imagine a time when a new PHP major was released in a ~yearly cycle, but I can not remember that somebody didn't consume those nor was hurt by that. * Which benefits does Zend Inc. see in contributing the Opcode cache? Simply put, this could benefit PHP greatly without negatively affecting our business in any way. And not simply put? Complexly put, this could benefit PHP greatly without negatively affecting our business in any way. I don't intend to become argumentative. You're obviously entitled to your opinion and I think that there's nothing I could say that would change it. Thanks for your feedback and please rest assured that I'm not entitled to any opinion about Zend in this case. Actually the opposite is the case which is why I was asking again. I normally would expect that there is something positive (in contrast to non-negative) in opening the source, e.g. getting a benefit from the collaborative development model. -- hakre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
- Ursprüngliche Message - Von: Zeev Suraski z...@zend.com An: hakre hanskren...@yahoo.de CC: internals@lists.php.net Gesendet: 17:47 Mittwoch, 30.Januar 2013 Betreff: RE: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution * In that RFC you write: the integration won’t happen before late 2014. [if it's not bundled with PHP 5.5] Can you please outline why? Based on an 18 month release cycle, and assuming we release 5.5.0 in mid 2013, 5.6.0 will come out late 2014. I wonder where you pick those quantifications from, according to https://wiki.php.net/rfc/releaseprocess there is 12 month cycle/tact, and according to the release date of PHP 5.4 major releases (golden) are scheduled for the first of march each year (alphas accordingly earlier). * Which benefits does Zend Inc. see in contributing the Opcode cache? Simply put, this could benefit PHP greatly without negatively affecting our business in any way. And not simply put? * Last but not least, not related to the opcode cache alone, but related because you want to bundle it with core: If some day the PHP group decides to choose a similar software license, but different in the sense that it is more compatible with existing FLOSS licensing, would you have a problem to re-license as well, e.g. under MIT or Apache 2.0 for that part? The plan is to contribute the source code to the PHP project. It'll be under the same license as PHP and subject to any changes in the PHP licensing scheme that we'll agree on. Who is that we in the last sentence? Could copyright be transfered to the PHP group? Which developers so far did work on that code? Do we get the release history as well? -- hakre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
Based on an 18 month release cycle, and assuming we release 5.5.0 in mid 2013, 5.6.0 will come out late 2014. I wonder where you pick those quantifications from, according to https://wiki.php.net/rfc/releaseprocess there is 12 month cycle/tact, and according to the release date of PHP 5.4 major releases (golden) are scheduled for the first of march each year (alphas accordingly earlier). I'm taking it from both reality and the discussions we had surrounding the release process RFC (in short, the 'yearly' in there was subject to change without notice; It's not an 11th commandment). I see good reasons not to go with a yearly release cycle, considering there's next to nobody actually interested in consuming those releases, but that's another story. * Which benefits does Zend Inc. see in contributing the Opcode cache? Simply put, this could benefit PHP greatly without negatively affecting our business in any way. And not simply put? Complexly put, this could benefit PHP greatly without negatively affecting our business in any way. I don't intend to become argumentative. You're obviously entitled to your opinion and I think that there's nothing I could say that would change it. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
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.jo...@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.jo...@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
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
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?
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
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.jo...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
Hi 2013/1/30 Stas Malyshev smalys...@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 ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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
RE: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
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:z...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
On 30 בינו 2013, at 16:57, John Carter jcar...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
* In that RFC you write: the integration won’t happen before late 2014. [if it's not bundled with PHP 5.5] Can you please outline why? Based on an 18 month release cycle, and assuming we release 5.5.0 in mid 2013, 5.6.0 will come out late 2014. Especially does it mean you stop contributing to the PECL development if you don't get this bundled with PHP 5.5? No. If you take a closer look at the options, the 'No' option reads 'Don’t integrate Optimizer+ to PHP, provide it as an optional component in PECL only'. We're going to publish the code as soon as we can, I hope no later than next week, and it'll be before we have the results of the vote. By 'integration' I refer to going beyond just including it in PECL, but including it in core. Also can you please outline why you put obviously so much focus in bundling this to PHP 5.5? Or is my impression wrong? Optimizer+ has been a free (closed source) component since 2008. We've been talking about open sourcing it numerous times over the years but it was never prioritized high enough. With the discussion last week about integrating an opcode cache into PHP's core, the challenges of using APC for that purpose on a short timeline, and the fact Optimizer+ is a significantly faster implementation than APC - I thought that this could be a good opportunity to commit ourselves (Zend) into doing this. Otherwise it would have probably never happened. To me, waiting for a couple of months to get a huge performance gain out-of-the-box is a no brainer. In fact, it might be a way to convince a lot of people that migrating is worth it. * With full respect and the best intentions: Are you able and if yes, can you share about the motivation why you decided (quite surprisingly) to contribute at this place in time? See above answer. You also wrote in an earlier email that you got out of sync with your userbase. I did not. Perhaps you read it that way :) Pierre said something along the lines of 'some people here being disconnected from our userbase'. I agreed with him, but obviously, I wasn't talking about myself. Under these circumstances, the impression could be that it took a little bit too long until this decision was done and I would like to see this impression clarified because there are many loose ends. Please bring up any loose ends you're spotting and I'll try to address them as best I can. * Is this surprising and welcomed release related in any way to the Openstack Initiative? Not at all. * Which benefits does Zend Inc. see in contributing the Opcode cache? Simply put, this could benefit PHP greatly without negatively affecting our business in any way. * Last but not least, not related to the opcode cache alone, but related because you want to bundle it with core: If some day the PHP group decides to choose a similar software license, but different in the sense that it is more compatible with existing FLOSS licensing, would you have a problem to re-license as well, e.g. under MIT or Apache 2.0 for that part? The plan is to contribute the source code to the PHP project. It'll be under the same license as PHP and subject to any changes in the PHP licensing scheme that we'll agree on. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
On Wed, Jan 30, 2013 at 5:47 PM, Zeev Suraski z...@zend.com wrote: * In that RFC you write: the integration won’t happen before late 2014. [if it's not bundled with PHP 5.5] Can you please outline why? Based on an 18 month release cycle, and assuming we release 5.5.0 in mid 2013, 5.6.0 will come out late 2014. it is more a 12-14 months actually. And it should be so. -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
-Original Message- From: Pierre Joye [mailto:pierre@gmail.com] Sent: Wednesday, January 30, 2013 7:22 PM To: Zeev Suraski Cc: hakre; PHP internals Subject: Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution On Wed, Jan 30, 2013 at 5:47 PM, Zeev Suraski z...@zend.com wrote: * In that RFC you write: the integration won't happen before late 2014. [if it's not bundled with PHP 5.5] Can you please outline why? Based on an 18 month release cycle, and assuming we release 5.5.0 in mid 2013, 5.6.0 will come out late 2014. it is more a 12-14 months actually. And it should be so. FWIW I think that's way too rapid (as I shared with you back in the day), but that's a topic for a different discussion. We have enough on our hands as it is :) Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
hi Zeev! On Tue, Jan 29, 2013 at 9:03 AM, Zeev Suraski z...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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)? (My guess is that it will show WP being slower and with a more dramatic improvement.) Thanks, -- Ryan McCue http://ryanmccue.info/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
On Tue, Jan 29, 2013 at 4:03 PM, Zeev Suraski z...@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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
On Tue, Jan 29, 2013 at 4:21 PM, Zeev Suraski z...@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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
-Original Message- From: Ryan McCue [mailto:li...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
On Tue, Jan 29, 2013 at 4:33 PM, Ivan Enderlin @ Hoa ivan.ender...@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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
On 2013/1/29 16:38, Laruence wrote: On Tue, Jan 29, 2013 at 4:33 PM, Ivan Enderlin @ Hoa ivan.ender...@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
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
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 z...@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. https://wiki.php.net/rfc/optimizerplus Comments welcome! Zeev
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
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 somme...@gmail.com wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
On Tue, Jan 29, 2013 at 11:26 AM, Florin Razvan Patan florinpa...@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
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
On 29 January 2013 11:23, Anthony Ferrara ircmax...@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?
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
Hi Zeev 2013/1/29 Zeev Suraski z...@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 ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
On Tue, Jan 29, 2013 at 2:27 PM, Kalle Sommer Nielsen ka...@php.net wrote: Hi Zeev 2013/1/29 Zeev Suraski z...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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? 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
-Original Message- From: kalle@gmail.com [mailto:kalle@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 z...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
Hi Pierre 2013/1/29 Pierre Joye pierre@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 ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
2013/1/29 Zeev Suraski z...@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 ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
-Original Message- From: Clint Priest [mailto:cpri...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
-Original Message- From: kalle@gmail.com [mailto:kalle@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 z...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
On Tue, Jan 29, 2013 at 2:52 PM, Rasmus Lerdorf ras...@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
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
2013/1/29 Zeev Suraski z...@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 ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
Hi Zeev, Am 29.01.2013 um 15:21 schrieb Rasmus Lerdorf ras...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
On Tue, Jan 29, 2013 at 3:21 PM, Rasmus Lerdorf ras...@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 :)
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
Kalle Sommer Nielsen wrote: 2013/1/29 Zeev Suraskiz...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
2013/1/29 Lester Caine les...@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 ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
On Tue, 29 Jan 2013, Zeev Suraski wrote: From: Clint Priest [mailto:cpri...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
Am 29.1.2013 um 15:58 schrieb Derick Rethans der...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
Kalle Sommer Nielsen wrote: 2013/1/29 Lester Caine les...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
-Original Message- From: Lars Strojny [mailto:l...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
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 BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
On Tue, 29 Jan 2013, Bob Weinand wrote: Am 29.1.2013 um 15:58 schrieb Derick Rethans der...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
On 29 בינו 2013, at 17:54, Derick Rethans der...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
On Tue, Jan 29, 2013 at 5:54 PM, Zeev Suraski z...@zend.com wrote: On 29 בינו 2013, at 17:54, Derick Rethans der...@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
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
Sent from my iPhone 6 Beta [Confidential use only] On 29 jan. 2013, at 18:02, Pierre Joye pierre@gmail.com wrote: On Tue, Jan 29, 2013 at 5:54 PM, Zeev Suraski z...@zend.com wrote: On 29 בינו 2013, at 17:54, Derick Rethans der...@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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
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.jo...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
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.jo...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
On Wed, Jan 30, 2013 at 1:17 AM, Christopher Jones christopher.jo...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
