subject:"Re\: \[PHP\-DEV\] \[VOTE\] Integrating Zend Optimizer\+ into the PHP distribution"

Nikita,



The 1-2 month estimation, is taken from about 50cm behind the fingers
typing this email, aka my gut J.  It’s quite possible it’ll take much less,
or no time at all;  But it’s possible that once we include it, a lot more
people test it, and we’ll get some feedback/requests/bugs that require
attention and additional RC’s – that we would otherwise not have.



Zeev



*From:* Nikita Popov [mailto:nikita@gmail.com]
*Sent:* Thursday, March 07, 2013 6:02 PM
*To:* Rasmus Lerdorf
*Cc:* Pierre Joye; Zeev Suraski; Laruence; PHP Developers Mailing List
*Subject:* Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP
distribution



On Sun, Mar 3, 2013 at 10:23 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:

On 03/03/2013 12:43 AM, Pierre Joye wrote:
 On Sun, Mar 3, 2013 at 8:41 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
 The

 first step towards integration is getting it in.

 That does not guarantee that further steps can be done, from a timely
manner.

There is never any such guarantee and the current results of the vote
clearly says that the majority of people are fine with a delayed 5.5
release.



The majority yes. The accessors proposal also had the majority in
favor, but that did not suffice. As of now this RFC does *not* have a 2/3
majority for the delay. And, as I already pointed out, I really think that
this RFC should go by a 2/3 vote, as it is both a very large change AND a
release delay.



But regardless of that, could somebody maybe point out where the it may
require a 1-2 month delay estimation in the RFC comes from? Somewhere
Rasmus said that the integration will not be tight and just a 30 minute
cleanup. I guess that was a bit exaggerated and may take a bit longer, but
in the same order of magnitude (like 3 hours instead of 30 minutes). By
that estimate the vote ends today and we can have ZO+ bundled in one or two
days. To let the change sink a bit, fix a few bugs that turn up and figure
out some questions like naming and default configuration one may need
another week, or maybe two. Then we should already be able to go for a beta
release. Everything else can be ironed out later (it's just a beta after
all and after that we have a good bit of time to fix issues that turn up).
Or did I miss something?

Nikita

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

2013-03-07 Thread Nikita Popov

On Thu, Mar 7, 2013 at 5:06 PM, Zeev Suraski z...@zend.com wrote:

 Nikita,



 The 1-2 month estimation, is taken from about 50cm behind the fingers
 typing this email, aka my gut J.  It’s quite possible it’ll take much
 less, or no time at all;  But it’s possible that once we include it, a lot
 more people test it, and we’ll get some feedback/requests/bugs that require
 attention and additional RC’s – that we would otherwise not have.



 Zeev


That makes sense, thanks. So just to be sure I got it right, we can expect
a swift beta, but anticipate that we'll need more releases after that to
fix issues that turn up?

Nikita

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

hi,

On Thu, Mar 7, 2013 at 5:01 PM, Nikita Popov nikita@gmail.com wrote:

 The majority yes. The accessors proposal also had the majority in favor,
 but that did not suffice. As of now this RFC does *not* have a 2/3 majority
 for the delay. And, as I already pointed out, I really think that this RFC
 should go by a 2/3 vote, as it is both a very large change AND a release
 delay.

I fully agree here. Bundling a default opcode cache (enabled by
default or not) is not a small decision and drastically affect the
future of PHP. The way it was handled was by far not ideal (last was
to edit the RFC during the voting phase without restarting the votes)
and I have some doubts about the openness of its future development.

 But regardless of that, could somebody maybe point out where the it may
 require a 1-2 month delay estimation in the RFC comes from?

An estimation, which is already not valid anymore. We are off the two
months. That's also why the beta1 planed today has been replaced with
an alpha instead.

 Somewhere
 Rasmus said that the integration will not be tight and just a 30 minute
 cleanup. I guess that was a bit exaggerated and may take a bit longer,

what takes longer is to stabilize it, there is no integration work
being done right now, as far as I can tell. Latest issues spotted in
our tests are visible in the report #63472.

 but
 in the same order of magnitude (like 3 hours instead of 30 minutes). By that
 estimate the vote ends today and we can have ZO+ bundled in one or two days.
 To let the change sink a bit, fix a few bugs that turn up and figure out
 some questions like naming and default configuration one may need another
 week, or maybe two. Then we should already be able to go for a beta release.
 Everything else can be ironed out later (it's just a beta after all and
 after that we have a good bit of time to fix issues that turn up). Or did I
 miss something?

Not really, betas are for testing and fixing. I did not follow the why
and how we did a release today but having a beta1 now without o+ would
mean that o+ would be 5.5 altogether, not that I would mind it, only a
statement.

That being said, if o+ would have 2/3 of the votes, I think it is
possible to get it stable until 5.5 final, not easy but possible.

Cheers,
-- 
Pierre

@pierrejoye

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

On Thu, Mar 7, 2013 at 5:06 PM, Zeev Suraski z...@zend.com wrote:
 Nikita,



 The 1-2 month estimation, is taken from about 50cm behind the fingers typing
 this email, aka my gut J.  It’s quite possible it’ll take much less, or no
 time at all;  But it’s possible that once we include it, a lot more people
 test it, and we’ll get some feedback/requests/bugs that require attention
 and additional RC’s – that we would otherwise not have.

You would have got much more feedback by doing pecl releases from day
one. Many people began to test it with the 1st pecl release.

Cheers,
-- 
Pierre

@pierrejoye

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

2013-03-07 Thread Rasmus Lerdorf

On 03/07/2013 08:26 AM, Pierre Joye wrote:

 That being said, if o+ would have 2/3 of the votes, I think it is
 possible to get it stable until 5.5 final, not easy but possible.

We already covered that. An opcode cache doesn't affect the language
itself. There is no new syntax and no BC issues. Much like a performance
improvement patch that has no effect on the language syntax doesn't need
2/3. Whether it is major or not, doesn't matter per the established
voting process. You can't both be a stickler for the details of this
process and then ignore them when they become inconvenient for you.

-Rasmus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

On Thu, Mar 7, 2013 at 5:31 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
 On 03/07/2013 08:26 AM, Pierre Joye wrote:

 That being said, if o+ would have 2/3 of the votes, I think it is
 possible to get it stable until 5.5 final, not easy but possible.

 We already covered that. An opcode cache doesn't affect the language
 itself. There is no new syntax and no BC issues.

It affects the whole PHP environment, o+ becomes the de facto
standard, it will replace APC or any other external projects per se in
the long run. If such a move does not affect PHP then I do not know
what else.

  Much like a performance
 improvement patch that has no effect on the language syntax doesn't need
 2/3. Whether it is major or not, doesn't matter per the established
 voting process. You can't both be a stickler for the details of this
 process and then ignore them when they become inconvenient for you.

Oh indeed, I do that. Come on.

But you'd to see that this RFC has been pushed badly in so many ways.
That's not fine. And you also (or should) know that I am (or was) one
of the 1st supporter to push into the core. We put our resources to
test, fix and valid every single change in it since it was OSSed.
However the way it is handled brings doubts, and I really don't want
to have doubts for such a critical piece of the PHP environment.

Cheers,
-- 
Pierre

@pierrejoye

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

2013-03-07 Thread Anthony Ferrara

Rasmus,

We already covered that. An opcode cache doesn't affect the language
 itself. There is no new syntax and no BC issues. Much like a performance
 improvement patch that has no effect on the language syntax doesn't need
 2/3. Whether it is major or not, doesn't matter per the established
 voting process. You can't both be a stickler for the details of this
 process and then ignore them when they become inconvenient for you.


To be fair, we did cover it, and we didn't come to a consensus. There were
a few people like yourself who believe it's not a language change and hence
requires 2/3... But there are a lot of other people (many who are raising
their hands now) who do believe it's a language level change and hence
requires 2/3. Sure, it doesn't effect syntax. But it can be considered a BC
change, as the internal zend API changes (not in terms of signatures, but
behaviors).

All I'm saying here is that while we did discuss it, no consensus was
achieved. So I don't think it's fair to say we already covered that.

Anthony

PS: How would we resolve something like this? Would it require a 2/3
meta-vote to determine if something needs a 2/3 vote? Seems like we're
hitting a limit of the RFC here that perhaps should be refactored...
Perhaps make everything require a 2/3 vote, and not have a distinction...

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

On Thu, Mar 7, 2013 at 5:31 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
 On 03/07/2013 08:26 AM, Pierre Joye wrote:

 That being said, if o+ would have 2/3 of the votes, I think it is
 possible to get it stable until 5.5 final, not easy but possible.

 We already covered that. An opcode cache doesn't affect the language
 itself. There is no new syntax and no BC issues. Much like a performance
 improvement patch that has no effect on the language syntax doesn't need
 2/3. Whether it is major or not, doesn't matter per the established
 voting process. You can't both be a stickler for the details of this
 process and then ignore them when they become inconvenient for you.


btw, I would even have included phar as affecting the language, as
even if you don't use it at all in your code, it affects how php
behaves. We had many issues related to phar while it was not used at
all in the code (due to the hooks). That's not exactly the same thing
than o+ but it has the same kind of possible impacts.

-- 
Pierre

@pierrejoye

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

Anthony,



As a rule of thumb, if the language syntax doesn’t change, it doesn’t need
a 2/3 vote.

How do I know?  I asked for this special majority in the first place.  It
was designed to protect the language from becoming the kitchen sink of
programming languages, not from making architectural progress.



If we need to amend the original voting RFC text so that it’s clearer –
let’s do that.  Right now it’s slightly ambiguous because it mentions
‘language syntax’ as an example, instead of outright saying that it’s about
that, period.



Zeev



*From:* Anthony Ferrara [mailto:ircmax...@gmail.com]
*Sent:* Thursday, March 07, 2013 6:44 PM
*To:* Rasmus Lerdorf
*Cc:* Pierre Joye; Nikita Popov; Zeev Suraski; Laruence; PHP Developers
Mailing List
*Subject:* Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP
distribution



Rasmus,



We already covered that. An opcode cache doesn't affect the language

itself. There is no new syntax and no BC issues. Much like a performance
improvement patch that has no effect on the language syntax doesn't need
2/3. Whether it is major or not, doesn't matter per the established
voting process. You can't both be a stickler for the details of this
process and then ignore them when they become inconvenient for you.



To be fair, we did cover it, and we didn't come to a consensus. There were
a few people like yourself who believe it's not a language change and hence
requires 2/3... But there are a lot of other people (many who are raising
their hands now) who do believe it's a language level change and hence
requires 2/3. Sure, it doesn't effect syntax. But it can be considered a BC
change, as the internal zend API changes (not in terms of signatures, but
behaviors).



All I'm saying here is that while we did discuss it, no consensus was
achieved. So I don't think it's fair to say we already covered that.



Anthony



PS: How would we resolve something like this? Would it require a 2/3
meta-vote to determine if something needs a 2/3 vote? Seems like we're
hitting a limit of the RFC here that perhaps should be refactored...
Perhaps make everything require a 2/3 vote, and not have a distinction...

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

On Thu, Mar 7, 2013 at 5:26 PM, Pierre Joye pierre@gmail.com wrote:

 what takes longer is to stabilize it, there is no integration work
 being done right now, as far as I can tell. Latest issues spotted in
 our tests are visible in the report #63472.

I mean #64372


--
Pierre

@pierrejoye

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

2013-03-07 Thread Julien Pauli

On Thu, Mar 7, 2013 at 5:46 PM, Pierre Joye pierre@gmail.com wrote:

 On Thu, Mar 7, 2013 at 5:31 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
  On 03/07/2013 08:26 AM, Pierre Joye wrote:
 
  That being said, if o+ would have 2/3 of the votes, I think it is
  possible to get it stable until 5.5 final, not easy but possible.
 
  We already covered that. An opcode cache doesn't affect the language
  itself. There is no new syntax and no BC issues. Much like a performance
  improvement patch that has no effect on the language syntax doesn't need
  2/3. Whether it is major or not, doesn't matter per the established
  voting process. You can't both be a stickler for the details of this
  process and then ignore them when they become inconvenient for you.


 btw, I would even have included phar as affecting the language, as
 even if you don't use it at all in your code, it affects how php
 behaves. We had many issues related to phar while it was not used at
 all in the code (due to the hooks). That's not exactly the same thing
 than o+ but it has the same kind of possible impacts.


And there comes the true definition of affects language behavior.
We still don't agree each other of what a major change, and a minor one
are, *and* : do we talk about user-level changes, or internals changes ? Or
both ?

That definitely needs to be clarified, or Anthony's idea of no distinction
on any RFC and make them require 2/3 to be accepted as well.

Julien.Pauli

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

2013-03-07 Thread Anthony Ferrara

Zeev,

As a rule of thumb, if the language syntax doesn’t change, it doesn’t need
 a 2/3 vote.

 How do I know?  I asked for this special majority in the first place.  It
 was designed to protect the language from becoming the kitchen sink of
 programming languages, not from making architectural progress.



 If we need to amend the original voting RFC text so that it’s clearer –
 let’s do that.  Right now it’s slightly ambiguous because it mentions
 ‘language syntax’ as an example, instead of outright saying that it’s about
 that, period.


Ambiguous writing is no excuse. People vote based on what is written, not
what was intended. Clarifying after the fact the intentions is not how RFCs
are designed to work. The point is that there's supposed to be clarity in
the text. And considering that the text is pretty clear that any change
affecting the language itself must have 2/3 majority, the question is not
what was intended by that statement, but if adopting ZO+ affects the
language (by interpretation).

So far, from what I've seen, you and Rasmus are the major people backing
the this is not a language change camp. In the other camp, there are
several people who have stood up and said that it does appear to be a
language change. I'm not trying to draw lines in the sand, but I'm trying
to point out that we have a disagreement that needs to be resolved.

Hand waving and saying it's not what I meant by that line shows nothing
but disrespect for the system and for everyone who participates in it...

So my proposal is to slow down for a minute and not call this RFC accepted
or not until we can come to some consensus as to if it classifies as a
language change or not... Better to clarify for the health of the project
than to plow through and risk causing further strife...

Anthony

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

2013-03-07 Thread Rasmus Lerdorf

On 03/07/2013 09:01 AM, Anthony Ferrara wrote:

 So my proposal is to slow down for a minute and not call this RFC
 accepted or not until we can come to some consensus as to if it
 classifies as a language change or not... Better to clarify for the
 health of the project than to plow through and risk causing further
 strife...

And how do you propose we do that? Vote on it? Will that vote need 2/3
as well? I think most of us accepted that language-level changes meant
syntax changes. Things that add new features to the language itself.

For example, interned strings in 5.4 was a major change as well and it
broke a bunch of things. I don't think we even bothered with an RFC for
it much less a vote since it was a really worthwhile performance
improvement which didn't affect the language at all other than the fact
that it broke a bunch of things, but once we worked out the bugs and
opcode caches eventually figured out how to support it, it became
invisible to the user. I don't see how adding an opcode cache is any
different. In fact adding this opcode cache will have less of an effect
than interned strings did since it doesn't touch the internals of the
engine anywhere near as much.

-Rasmus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

Anthony,



94% of the votes voted in favor of integrating O+ into PHP, which is well
above 2/3, it’s almost 3/3.  The only open question was about timeline.
And no matter how we twist it, whether it happens now or in a year has
ABSOLUTELY nothing to do with whether or not it’s a language change.  In
other words, if I phrased the RFC differently, and only asked who’s in
favor vs. who’s against – it would get a 94% vote in favor, easily blowing
past both the 51% barrier as well as the 67% barrier.  A 2nd RFC, asking
people to vote about the timeline – would have gotten 44 vs 22, which
happens to be 2/3, but clearly, would not have required more than 51% since
it’s a timeline question, not a language change question.



I’m afraid that’s as far as I’m willing to play this game of bureaucracy.
The voting RFC wasn’t designed to turn PHP into The House, or a courtroom.
There’s absolutely NO WAY we can reach consensus, and there’s no way the
overwhelming majority would agree to paralysis imposed by a tiny minority.
Let’s put it to rest, we all have better things to do with our time.



Zeev





*From:* Anthony Ferrara [mailto:ircmax...@gmail.com]
*Sent:* Thursday, March 07, 2013 7:02 PM
*To:* Zeev Suraski
*Cc:* Rasmus Lerdorf; Nikita Popov; Laruence; PHP Developers Mailing List
*Subject:* Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP
distribution



Zeev,



As a rule of thumb, if the language syntax doesn’t change, it doesn’t need
a 2/3 vote.

How do I know?  I asked for this special majority in the first place.  It
was designed to protect the language from becoming the kitchen sink of
programming languages, not from making architectural progress.



If we need to amend the original voting RFC text so that it’s clearer –
let’s do that.  Right now it’s slightly ambiguous because it mentions
‘language syntax’ as an example, instead of outright saying that it’s about
that, period.



Ambiguous writing is no excuse. People vote based on what is written, not
what was intended. Clarifying after the fact the intentions is not how RFCs
are designed to work. The point is that there's supposed to be clarity in
the text. And considering that the text is pretty clear that any change
affecting the language itself must have 2/3 majority, the question is not
what was intended by that statement, but if adopting ZO+ affects the
language (by interpretation).



So far, from what I've seen, you and Rasmus are the major people backing
the this is not a language change camp. In the other camp, there are
several people who have stood up and said that it does appear to be a
language change. I'm not trying to draw lines in the sand, but I'm trying
to point out that we have a disagreement that needs to be resolved.



Hand waving and saying it's not what I meant by that line shows nothing
but disrespect for the system and for everyone who participates in it...



So my proposal is to slow down for a minute and not call this RFC accepted
or not until we can come to some consensus as to if it classifies as a
language change or not... Better to clarify for the health of the project
than to plow through and risk causing further strife...



Anthony

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

On Thu, Mar 7, 2013 at 6:18 PM, Zeev Suraski z...@zend.com wrote:

 94% of the votes voted in favor of integrating O+ into PHP, which is well
 above 2/3, it’s almost 3/3.


44 for 5.5 + delay

22 for no delay (aka 5.6)

4 for not at all in the current sate

Sorry but don't use numbers badly to cover your goals.

 The only open question was about timeline.

It is the main question, not the last open (there are many).

 And no matter how we twist it, whether it happens now or in a year has
 ABSOLUTELY nothing to do with whether or not it’s a language change.  In
 other words, if I phrased the RFC differently, and only asked who’s in
 favor vs. who’s against – it would get a 94% vote in favor,



 easily blowing
 past both the 51% barrier as well as the 67% barrier.  A 2nd RFC, asking
 people to vote about the timeline – would have gotten 44 vs 22, which
 happens to be 2/3, but clearly, would not have required more than 51% since
 it’s a timeline question, not a language change question.

It is clearly not as clear as you think.

 I’m afraid that’s as far as I’m willing to play this game of bureaucracy.
 The voting RFC wasn’t designed to turn PHP into The House, or a courtroom.
 There’s absolutely NO WAY we can reach consensus, and there’s no way the
 overwhelming majority would agree to paralysis imposed by a tiny minority.
 Let’s put it to rest, we all have better things to do with our time.

Yes, but what should be put on rest is not the RFCs process, which
work out of the box for 99.99% but the way you habdle it and the total
lack of respect for the different opinions raised here or on other
lists. That'd to end at some point.

Cheers,
--
Pierre

@pierrejoye

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

2013-03-07 Thread Lars Strojny

Yay!

Am 07.03.2013 um 17:48 schrieb Zeev Suraski z...@zend.com:

 The voting period ended, and the option selected with 44 out of 70 votes
 was integrating Optimizer+ into PHP 5.5.0, even at the cost of a minor
 delay.  An overwhelming majority (66 out of the 70 votes) was in favor of
 going with the integration in general.
 
 
 
 We’ll work on moving the repository as soon as possible so that we can push
 out a new 5.5.0 package that includes it.  Another couple of things we need
 to tackle are .ini option naming (probably “opcache.” instead of
 “zend_optimizerplus.”) and default status (enabled or disabled by default
 by default).
 
 
 
 Zeev
 
 
 
 
 
 *From:* Zeev Suraski [mailto:z...@zend.com]
 *Sent:* Wednesday, February 27, 2013 6:13 PM
 *To:* 'PHP Developers Mailing List'
 *Subject:* [VOTE] Integrating Zend Optimizer+ into the PHP distribution
 
 
 
 Based on the overwhelming response, the vote is now open J
 
 
 
 https://wiki.php.net/rfc/optimizerplus
 
 
 
 Voting ends March 7th.
 
 
 
 Zeev


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

2013-03-07 Thread David Soria Parra

On 2013-03-07, Rasmus Lerdorf ras...@lerdorf.com wrote:
 On 03/07/2013 09:01 AM, Anthony Ferrara wrote:

 So my proposal is to slow down for a minute and not call this RFC
 accepted or not until we can come to some consensus as to if it
 classifies as a language change or not... Better to clarify for the
 health of the project than to plow through and risk causing further
 strife...

 And how do you propose we do that? Vote on it? Will that vote need 2/3
 as well? I think most of us accepted that language-level changes meant
 syntax changes. Things that add new features to the language itself.

I think the only thing requiring a 2/3 vote would be the decision on
wheather to enable it by default or not. As long as it's in ext/
and not enabled a 50% should be sufficient.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

2013-03-07 Thread Philip Olson


On Mar 7, 2013, at 1:00 PM, David Soria Parra d...@php.net wrote:

 On 2013-03-07, Rasmus Lerdorf ras...@lerdorf.com wrote:
 On 03/07/2013 09:01 AM, Anthony Ferrara wrote:
 
 So my proposal is to slow down for a minute and not call this RFC
 accepted or not until we can come to some consensus as to if it
 classifies as a language change or not... Better to clarify for the
 health of the project than to plow through and risk causing further
 strife...
 
 And how do you propose we do that? Vote on it? Will that vote need 2/3
 as well? I think most of us accepted that language-level changes meant
 syntax changes. Things that add new features to the language itself.
 
 I think the only thing requiring a 2/3 vote would be the decision on
 wheather to enable it by default or not. As long as it's in ext/
 and not enabled a 50% should be sufficient.

Shouldn't we be focusing on how this makes PHP better? And not nitpick 
about a percentage point or two? 

This makes PHP better. Please, PHP, add it to 5.5. 

Regards,
Philip


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

On 7 במרץ 2013, at 23:00, David Soria Parra d...@php.net wrote:

 On 2013-03-07, Rasmus Lerdorf ras...@lerdorf.com wrote:
 On 03/07/2013 09:01 AM, Anthony Ferrara wrote:

 So my proposal is to slow down for a minute and not call this RFC
 accepted or not until we can come to some consensus as to if it
 classifies as a language change or not... Better to clarify for the
 health of the project than to plow through and risk causing further
 strife...

 And how do you propose we do that? Vote on it? Will that vote need 2/3
 as well? I think most of us accepted that language-level changes meant
 syntax changes. Things that add new features to the language itself.

 I think the only thing requiring a 2/3 vote would be the decision on
 wheather to enable it by default or not. As long as it's in ext/
 and not enabled a 50% should be sufficient.

Not that I worry, but how do we reach that conclusion?
Rasmus had a good point.  We didn't even vote about interned strings
(and that's a good thing), and I'm doubtful that if we did find it
necessary to vote for it, we'd find that more than 51% is needed.  How
is enabling O+ different?  Or do we need a vote, and even a 2/3 vote,
for every significant perf improvement?

Again, I don't really worry - given that 94% of voters voted in favor
of embracing O+ (and honestly I'd love to get wider user feedback from
5.5 evaluators before we take this call) - but I'm worried that 2/3
voting requirement will become arbitrary, and not what it was designed
to serve - a way from protecting the language from a flood of
irreversible changes.

Zeev

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

2013-03-07 Thread David Soria Parra

On 03/07/2013 10:33 PM, Philip Olson wrote:
 I think the only thing requiring a 2/3 vote would be the decision on
 wheather to enable it by default or not. As long as it's in ext/
 and not enabled a 50% should be sufficient.
 
 Shouldn't we be focusing on how this makes PHP better? And not nitpick 
 about a percentage point or two? 

I agree, no need for lawyers and nitpicking.


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

2013-03-07 Thread Anthony Ferrara

Philip,

Shouldn't we be focusing on how this makes PHP better? And not nitpick
 about a percentage point or two?


Well, this passed with 62.8%. Property accessors failed with 60.7%. The
target for acceptance is 66.6%. So 3.8% is enough to throw away, but 5.9%
isn't?

I think the point of this discussion is that rules are rules for a reason.
You can't be high and holy and deny one RFC judiciously, and then hand-wave
and say the next RFC doesn't matter because the intention is there (or
whatever rationale is).

Either we stick to the rules, or we throw them out and install a BDFL.
Either way, I don't care. I just think the current
they-sometimes-matter-depending-on-who-and-when-it-is-raised stance is
deeper than BS, it's dangerous and is actively turning away contributors
(as well as harming the project)...

Anthony

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

2013-03-07 Thread Arpad Ray

On Thu, Mar 7, 2013 at 9:58 PM, Anthony Ferrara ircmax...@gmail.com wrote:

 Well, this passed with 62.8%. Property accessors failed with 60.7%. The
 target for acceptance is 66.6%. So 3.8% is enough to throw away, but 5.9%
 isn't?


94% voted to integrate ZO+.


 Either we stick to the rules, or we throw them out and install a BDFL.
 Either way, I don't care. I just think the current
 they-sometimes-matter-depending-on-who-and-when-it-is-raised stance is
 deeper than BS, it's dangerous and is actively turning away contributors
 (as well as harming the project)...


Oh, please...

Arpad

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

2013-03-07 Thread Philip Olson


On Mar 7, 2013, at 1:58 PM, Anthony Ferrara ircmax...@gmail.com wrote:

 Philip,
 
 Shouldn't we be focusing on how this makes PHP better? And not nitpick
 about a percentage point or two?
 
 
 Well, this passed with 62.8%. Property accessors failed with 60.7%. The
 target for acceptance is 66.6%. So 3.8% is enough to throw away, but 5.9%
 isn't?
 
 I think the point of this discussion is that rules are rules for a reason.
 You can't be high and holy and deny one RFC judiciously, and then hand-wave
 and say the next RFC doesn't matter because the intention is there (or
 whatever rationale is).
 
 Either we stick to the rules, or we throw them out and install a BDFL.
 Either way, I don't care. I just think the current
 they-sometimes-matter-depending-on-who-and-when-it-is-raised stance is
 deeper than BS, it's dangerous and is actively turning away contributors
 (as well as harming the project)…


Hello Anthony,

Good points. And the vague release/voting RFCs also contribute to this.

And FWIW, I think PHP needs a BDFL, but we'll have to convince the one 
potential candidate to agree. :)

Regards,
Philip


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

2013-03-07 Thread Andi Gutmans

-Original Message-
From: Anthony Ferrara [mailto:ircmax...@gmail.com]
Sent: Thursday, March 07, 2013 1:58 PM
To: Philip Olson
Cc: David Soria Parra; internals@lists.php.net
Subject: Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP
distribution

Philip,

Shouldn't we be focusing on how this makes PHP better? And not nitpick
 about a percentage point or two?

Well, this passed with 62.8%. Property accessors failed with 60.7%. The
target
for acceptance is 66.6%. So 3.8% is enough to throw away, but 5.9% isn't?

I think the point of this discussion is that rules are rules for a
reason.
You can't be high and holy and deny one RFC judiciously, and then hand-
wave and say the next RFC doesn't matter because the intention is there
(or
whatever rationale is).

I have to say I wasn't sure whether to laugh or cry at some of the
ludicrous statements that have been made here.

The 2/3 vote rule was meant to protect the language from not becoming
bloated, i.e. language syntax feature creep. This has been a serious
concern for many of us over the past years with just an ever increasing
flood of new language syntax suggestions coming in. I think very few of us
looked at that as a catch-all for any infrastructure change in PHP incl.
evolving PHP extensions, core runtime changes, etc..

The 62.8% comparison to 60.7% is the most out of touch thing I've read on
this mailing list in a long time. If you're talking about pure feature
yay/nay then 94% have given a yay to this feature. The split is the
timing.

And as far as timing is concerned I do not see how this whole thing falls
into the 2/3 vote for new language syntax/prevent feature creep rule.
Many times in the past have we aligned new PHP versions with runtime
improvements esp. as they are often exciting and beneficial to most of our
audience. I don't see why we wouldn't do that given that the cost is
pretty minimal and the benefit to our audience is high.

Andi

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

2013-03-04 Thread Lars Strojny

Hi Zeev,

Am 28.02.2013 um 21:16 schrieb Zeev Suraski z...@zend.com:

 Ideally I'd like to get Xdebug compatibility for 5.5 - but even if we can't
 make it - there's truth to the assertion you wouldn't want them both at the
 same time.

That’s not entirely true. If you stay as similar as possible to your production 
environment, your development environment will have an opcode cache as well. 
And possibly xdebug.

cu,
Lars
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

2013-03-04 Thread Herman Radtke

 Ideally I'd like to get Xdebug compatibility for 5.5 - but even if we can't
 make it - there's truth to the assertion you wouldn't want them both at the
 same time.

 That’s not entirely true. If you stay as similar as possible to your 
 production environment, your development environment will have an opcode 
 cache as well. And possibly xdebug.

I run xdebug on 1% of my production servers to a nice stack trace for
errors that reveal themselves in production. Similar to how I run
xhprof on 1% of all web requests.

-- 
Herman Radtke
@hermanradtke | http://hermanradtke.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

2013-03-04 Thread Zeev Suraski

 -Original Message-
 From: Lars Strojny [mailto:l...@strojny.net]
 Sent: Tuesday, March 05, 2013 12:31 AM
 To: Zeev Suraski
 Cc: Anthony Ferrara; Nikita Popov; PHP Developers Mailing List
 Subject: Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP
 distribution

 Hi Zeev,

 Am 28.02.2013 um 21:16 schrieb Zeev Suraski z...@zend.com:

  Ideally I'd like to get Xdebug compatibility for 5.5 - but even if we
  can't make it - there's truth to the assertion you wouldn't want them
  both at the same time.

 That's not entirely true. If you stay as similar as possible to your
production
 environment, your development environment will have an opcode cache as
 well. And possibly xdebug.

I agree it's not entirely true, which is why I said there's only 'some'
truth to it :)  In other words, I think it's desirable that they would
both work together, but if they don't, it's not the end of the world.

But again, they already work together fairly well and we'll hopefully make
them work together even better.

Zeev

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

2013-03-03 Thread Pierre Joye

On Sun, Mar 3, 2013 at 8:41 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:

 The RFC is about integrating O+ into PHP which can by definition only
 happen in 5.5 and later.

Implicitly no, while it is clear that it has to be done. But
explicitly the RFC uses the word integration for 5.5 and it won't
happen. However what is voted on is:

Integrate into 5.5, even if minor delay required
Integrate into 5.5 only if it's not delayed, otherwise  - 5.6
Don’t integrate Optimizer+ to PHP

And what will actually happen if accepted is bundlingcleanup for 5.5,
integration in 5.6 or later.

That makes a rather huge difference, especially when it is about
delaying 5.5 for a relatively unknown period. It is even more
disturbing as the gain between that and having it in PECL for the
meantime is very very low.

A real integration (at least partially) may be done it during the beta
phases but I very much doubt that it is feasible, stabilize it will
likely take more time and beginning to do many changing to actually
integrate o+ into core is way too risky during beta/RC phases.

 The essential questions being asked by the RFC
 are whether to delay 5.5 for it, no delay and wait until the next
 version, or don't integrate at all the last of which implies
 external-only distribution either through pecl or individual distros
 simply packaging it from Github.

Distros will distribute it as separate packages anyway, I do not
really the point here.

 And your beef about integration vs. bundling is rather nit-picky.

No, it is not. Hence why I asked to have the roadmap (no date but a
plan and actual actions listed) to have an informed vote.

 The
 first step towards integration is getting it in.

That does not guarantee that further steps can be done, from a timely manner.

 How much integration is
 done will depend on what people come up with. I have a pull request in
 for at least one level of integration that will allow it to save a stat
 call by integrating more closely with the sapi layer to save that
 initial stat if the sapi layer can pull it from the server layer.

 That
 is more than mere bundling, but it should also be rather safe to do.

That is done in APC already. Any extensions can use it, being in core or not.

 What we do about earlier versions is a completely separate and mostly
 unrelated issue. There is no real reason not to support those via pecl,
 but that isn't what this RFC is about. And, like you say, there is
 nothing stopping you or anybody else from making a pointer to it from pecl.

I agree, it is a separate issue. However it does affect the decision
about delaying 5.5 for it while everything do or add can be done via
pecl. That's why I think everything should be part of the RFC so
voters can take an informed decision based on the actual planed moves.
The question about little 5.4 adoption because of the lack of opcode
cache support does not apply to 5.5 and o+ as it already supports
quite well, minus the remaining issues (see Matt's post earlier this
week).

But again, I am not trying to stop o+ being in core, but the contrary.
Almost all our (my team colleagues) resources are on testing 5.5 and
o+ (and APC too as a fallback). We also provided patches, use cases,
etc. we discovered or implemented while testing 5.3/4/5 and o+ with
our tests benchmarks. My only point is the actual gain to delay 5.5
even more without knowing when we can release it, shooting in the dark
and the lack of PECL support for previous php versions (as in: won't
reduce our work load because we will still have to support APC as a
prio #1 for 5.3/4).

Cheers,
--
Pierre

@pierrejoye

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

2013-03-03 Thread Rasmus Lerdorf

On 03/03/2013 12:43 AM, Pierre Joye wrote:
 On Sun, Mar 3, 2013 at 8:41 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
 The
 first step towards integration is getting it in.
 
 That does not guarantee that further steps can be done, from a timely manner.

There is never any such guarantee and the current results of the vote
clearly says that the majority of people are fine with a delayed 5.5
release.

 How much integration is
 done will depend on what people come up with. I have a pull request in
 for at least one level of integration that will allow it to save a stat
 call by integrating more closely with the sapi layer to save that
 initial stat if the sapi layer can pull it from the server layer.

 That
 is more than mere bundling, but it should also be rather safe to do.
 
 That is done in APC already. Any extensions can use it, being in core or not.

So? It is not done in O+. The fact that APC is better integrated on this
particular point doesn't invalidate this as a low-hanging fruit
integration step for O+. And there are other such low-hanging fruits we
are likely to find, test and deem stable enough to get into 5.5.

 What we do about earlier versions is a completely separate and mostly
 unrelated issue. There is no real reason not to support those via pecl,
 but that isn't what this RFC is about. And, like you say, there is
 nothing stopping you or anybody else from making a pointer to it from pecl.
 
 I agree, it is a separate issue. However it does affect the decision
 about delaying 5.5 for it while everything do or add can be done via
 pecl. That's why I think everything should be part of the RFC so
 voters can take an informed decision based on the actual planed moves.
 The question about little 5.4 adoption because of the lack of opcode
 cache support does not apply to 5.5 and o+ as it already supports
 quite well, minus the remaining issues (see Matt's post earlier this
 week).
 
 But again, I am not trying to stop o+ being in core, but the contrary.

No, but you are certainly trying to delay it by suggesting that the
current RFC needs to be rewritten and presumably voting restarted at
which point you can shout louder about how much this is delaying the 5.5
release because you will have added a month of purely process time to
the mix.

The fact is that the current release managers support delaying the
release on the chance that we can get a stable opcode cache into this
release and there is decent majority support for this approach according
to our own process however faulty it may be, so I would ask you to stand
down and let us do our thing instead of getting in the way.

-Rasmus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

2013-03-03 Thread Zeev Suraski

 -Original Message-
 From: Pierre Joye [mailto:pierre@gmail.com]
 Sent: Sunday, March 03, 2013 9:26 AM
 To: Zeev Suraski
 Cc: Laruence; PHP Developers Mailing List
 Subject: Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP
 distribution

 On Sun, Mar 3, 2013 at 8:21 AM, Zeev Suraski z...@zend.com wrote:
  How Don't integrate Optimizer+ to PHP can be remotely related to
  the available of o+ via PECL?

  Actually it seems as if some of the original text got lost when I
  switched to the active vote, but it used to read 'Don't integrate
  Optimizer+ to PHP, release only in PECL'.  My bad.

 No offense and pls do not see what I will say here as an attempt to
block it, as I
 really want o+ in core.

 I think this RFC should be fixed (fix wording to represent the actual
actions,
 s,integration,bundlingcleanup,), votes options added to cover what has
been
 discussed. Add a roadmap as well for the further steps that
can/could/will be
 taken to make o+ even better while being in core.

Pierre,

The whole 'integration' point is well defined in the RFC under the 'PHP
5.5.0 section'.  There's no tight integration on the table.  The delay is
also defined as anywhere between 0 and 1-2 months, it's not open-ended.

I added a bit of clarifying text to the 3rd option, to ensure people
understand this would mean we make it avail through PECL.

I'm not going to add additional voting options at this point.  Look
around, the a strong majority of devs and the vast majority of core devs
wants it in 5.5.0, and not continue hashing with bureaucracy.  We'd really
love to be done with the discussion instead of restarting it.

Zeev

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

2013-03-02 Thread David Soria Parra

On 2013-02-27, Zeev Suraski z...@zend.com wrote:
 On 27  2013, at 18:58, Anthony Ferrara ircmax...@gmail.com wrote:

 Zeev et al,

 I just want to put my justification for the only if no delay vote. I voted 
 that way because we're already at a significant delay. If this vote was a 
 month ago when O+ was suggested first, I would definitely have voted for 
 delay. In fact IIRC I proposed a delay back then. But after a month, I 
 think delaying much further would be imprudent.


 Fair enough!  Here's mine for delaying:

 I believe our users will much appreciate a release with an opcode
 cache that's several months delayed vs. one that's without an opcode
 cache several months early.  If the 5.4 adoption rate (or complete
 lack thereof) is any indication - very few are eagerly waiting for
 5.5.  In fact, in a year's time, when we all gear up to release 5.6
 (based on current frequency) - 5.5 is almost guaranteed to have next
 to no traction in our userbase.  A bundled opcode cache might be the
 killer feature that makes the difference.

I agree with zeev here. The opcode cache is one of the most important
thing for adoption. With apc not being 5.4 compatible and 5.3 eol with 5.6, 
there is no real transition for people relying on an opcode cache if we don't
delay 5.5. That's the only reason why Julien and I so far delayed it.


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

2013-03-02 Thread Laruence

On Thu, Feb 28, 2013 at 2:53 PM, Pierre Joye pierre@gmail.com wrote:
 On Wed, Feb 27, 2013 at 5:12 PM, Zeev Suraski z...@zend.com wrote:
 Based on the overwhelming response, the vote is now open J



 https://wiki.php.net/rfc/optimizerplus



 Voting ends March 7th.

 ok, given the total lack of answers, mistakes and misleading wording
 in the RFC and lack of releases in PECL (which is a pre requise since
 quite some time to get in core), I'd to vote -1 for now.
+1,

there should be a option release at PECL,  which will give the O+
more feedback and test

thanks

 It will surely won't change anything but I stand to what we discuss.

 --
 Pierre

 @pierrejoye

 --
 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] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

2013-03-02 Thread Pierre Joye

hi Zeev,

On Sun, Mar 3, 2013 at 8:02 AM, Zeev Suraski z...@zend.com wrote:

 ok, given the total lack of answers, mistakes and misleading wording

 in the RFC and lack of releases in PECL (which is a pre requise since

 quite some time to get in core), I'd to vote -1 for now.

 +1,

 there should be a option release at PECL,  which will give the O+
 more feedback and test


 There is one, its the third option.


Ok this is getting ridiculous.

How Don’t integrate Optimizer+ to PHP can be remotely related to the
available of o+ via PECL?

No matter the results, having o+ available in PECL for  5.5 is a very
good thing and many are expecting as well. Not doing it means that
only 5.5 is supported and that defeats the whole purpose of having one
opcode cache to rule them all. Why? Because we will still have to use
most of our resources to support APC and wincache for 5.3 and 5.4.

At some point I think I will simply do it myself and be done with this
sterile discussion, it is OSS anyway and the license allows anyone to
do it.

Cheers,
--
Pierre

@pierrejoye

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

2013-03-02 Thread Zeev Suraski

 How Don't integrate Optimizer+ to PHP can be remotely related to the
 available of o+ via PECL?

Actually it seems as if some of the original text got lost when I switched
to the active vote, but it used to read 'Don't integrate Optimizer+ to
PHP, release only in PECL'.  My bad.

Zeev

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

2013-03-02 Thread Pierre Joye

On Sun, Mar 3, 2013 at 8:21 AM, Zeev Suraski z...@zend.com wrote:
 How Don't integrate Optimizer+ to PHP can be remotely related to the
 available of o+ via PECL?

 Actually it seems as if some of the original text got lost when I switched
 to the active vote, but it used to read 'Don't integrate Optimizer+ to
 PHP, release only in PECL'.  My bad.


No offense and pls do not see what I will say here as an attempt to
block it, as I really want o+ in core.

I think this RFC should be fixed (fix wording to represent the actual
actions, s,integration,bundlingcleanup,), votes options added to
cover what has been discussed. Add a roadmap as well for the further
steps that can/could/will be taken to make o+ even better while being
in core.

The options should include PECL, either it is in core or not. So you
can get an idea about how many people wants  5.5 support and releases
as well.

Cheers,
-- 
Pierre

@pierrejoye

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

2013-03-02 Thread Rasmus Lerdorf

On 03/02/2013 11:25 PM, Pierre Joye wrote:
 On Sun, Mar 3, 2013 at 8:21 AM, Zeev Suraski z...@zend.com wrote:
 How Don't integrate Optimizer+ to PHP can be remotely related to the
 available of o+ via PECL?

 Actually it seems as if some of the original text got lost when I switched
 to the active vote, but it used to read 'Don't integrate Optimizer+ to
 PHP, release only in PECL'.  My bad.
 
 
 No offense and pls do not see what I will say here as an attempt to
 block it, as I really want o+ in core.
 
 I think this RFC should be fixed (fix wording to represent the actual
 actions, s,integration,bundlingcleanup,), votes options added to
 cover what has been discussed. Add a roadmap as well for the further
 steps that can/could/will be taken to make o+ even better while being
 in core.
 
 The options should include PECL, either it is in core or not. So you
 can get an idea about how many people wants  5.5 support and releases
 as well.

The RFC is about integrating O+ into PHP which can by definition only
happen in 5.5 and later. The essential questions being asked by the RFC
are whether to delay 5.5 for it, no delay and wait until the next
version, or don't integrate at all the last of which implies
external-only distribution either through pecl or individual distros
simply packaging it from Github.

And your beef about integration vs. bundling is rather nit-picky. The
first step towards integration is getting it in. How much integration is
done will depend on what people come up with. I have a pull request in
for at least one level of integration that will allow it to save a stat
call by integrating more closely with the sapi layer to save that
initial stat if the sapi layer can pull it from the server layer. That
is more than mere bundling, but it should also be rather safe to do.

What we do about earlier versions is a completely separate and mostly
unrelated issue. There is no real reason not to support those via pecl,
but that isn't what this RFC is about. And, like you say, there is
nothing stopping you or anybody else from making a pointer to it from pecl.

-Rasmus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

2013-03-01 Thread Sebastian Bergmann

On 02/28/2013 02:34 PM, Anthony Ferrara wrote:
 example, XDebug has no compatibility with ZendOptimizer+ right now (at
 least that I could find, feel free to correct me if I'm wrong here).

 I tested PHPUnit with both Xdebug and ZO+ enabled and got a correct
 code coverage report. So at least that part of Xdebug is compatible
 with ZO+.


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

2013-02-28 Thread Kalle Sommer Nielsen

Den 28/02/2013 kl. 07.53 skrev Pierre Joye pierre@gmail.com:

 
 ok, given the total lack of answers, mistakes and misleading wording
 in the RFC and lack of releases in PECL (which is a pre requise since
 quite some time to get in core), I'd to vote -1 for now.

My reasons exactly for now, while it is tempting to vote against our own 
agreements

-K
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

 -Original Message-
 From: Pierre Joye [mailto:pierre@gmail.com]
 Sent: Thursday, February 28, 2013 12:17 AM
 To: Rasmus Lerdorf
 Cc: Ferenc Kovacs; Zeev Suraski; PHP Developers Mailing List
 Subject: Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP
 distribution

 Now, about the yearly release, every single person I talked to love it
and want us
 to keep with this cycle, as well as the more frequent bugs fixes
releases. One
 thing we have to slightly change is to push too many new features in
each of
 them, but we will get there.

I'm not sure how many people you've spoken to and what their profile is,
but reality shows a very different picture:

481004 PHP/5.2.17
 280342 PHP/5.3.8
 271156 PHP/5.2.6-1+lenny16
146342 PHP/5.2.9
 133818 PHP/5.2.6
 125550 PHP/5.3.10
 109513 PHP/5.2.6-1+lenny13
 106320 PHP/5.2.5
 102412 PHP/5.2.14
  81221 PHP/5.2.6-1+lenny9

These are the top-10 most popular PHP 5.x versions out there.  PHP 5.4.x,
in case you're wondering, shows up on the 44th place, with a bit over 20K
deployments worldwide (5.4.11).
With yearly release cycles, we may make the lives of a few users more
enjoyable and with more rapid access to new features;  But for the vast
majority, we're actually making lives worse:

1. Framework  app developers can't really rely on new features anyway,
since nobody has those new versions installed.  Just two years ago -
aiming for PHP 5.3 seemed like a bold move for ZF2 and Sf2 - and that's
even though PHP 5.3 brought some revolutionary features to the mix (which
5.4 and 5.5 do not).  We've also heard the Wordpress way of thinking, and
we can assume that it'd take many years before other apps feel comfortable
requiring a higher version than 5.3.x as a prerequisite.
2. Users who want to stay secure have to constantly upgrade, since support
lifetimes have been trimmed down substantially (effectively, 3 years from
release;  and considering nobody upgrades on to an x.y.0 version, it's
typically way less than that).  We can already project that based on the
current frequency, people who install PHP 5.4 today will have less than
two years-worth of lifetime before they're forced to upgrade, or be left
unsupported.
3.  For the ecosystem in general, we're creating lots of fragmentation.

All in all, I think the people who like the yearly release cycle are first
and foremost bleeding edge individual developers, and not people who are a
part of larger projects, or that actually have to worry about production
apps working uninterrupted.

Zeev

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

2013-02-28 Thread Frank Schenk

Hi,

Am 02/28/2013 11:21 AM, schrieb Zeev Suraski:
 I'm not sure how many people you've spoken to and what their profile is,
 but reality shows a very different picture:
 
 481004 PHP/5.2.17
  280342 PHP/5.3.8

you can add another ~100 PHP/5.3.8 installations.

For our company stability and bug fixes are way more important (like
10fold) than having fancy new features. I was asked, if we can switch to
5.4.x but i refused, because it's a couple of days work for each project
to evaluate and migrate to 5.4.x

 All in all, I think the people who like the yearly release cycle are first
 and foremost bleeding edge individual developers, and not people who are a
 part of larger projects, or that actually have to worry about production
 apps working uninterrupted.

I personally totally agree.

Cheers, Frank

-- 

Frank Schenk
Software Analyst
2e Systems

Tel: +49 - 6196 - 95058 - 30
Fax: +49 - 6196 - 95058 - 94
E-mail: frank.sch...@2e-systems.com

Address: 2e Systems GmbH, Königsteiner Str. 87, D-65812 Bad Soden am Taunus
Company registration: Amtsgericht Königstein (Germany), HRB 7303
Director: Philip Douglas

http://www.2e-systems.com/ - making your business fly!

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

2013-02-28 Thread Lester Caine

Zeev Suraski wrote:

-Original Message-
From: Pierre Joye [mailto:pierre@gmail.com]
Sent: Thursday, February 28, 2013 12:17 AM
To: Rasmus Lerdorf
Cc: Ferenc Kovacs; Zeev Suraski; PHP Developers Mailing List
Subject: Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP
distribution

Now, about the yearly release, every single person I talked to love it

and want us

to keep with this cycle, as well as the more frequent bugs fixes

releases. One

thing we have to slightly change is to push too many new features in

each of

them, but we will get there.

I'm not sure how many people you've spoken to and what their profile is,
but reality shows a very different picture:

481004 PHP/5.2.17
  280342 PHP/5.3.8
  271156 PHP/5.2.6-1+lenny16
146342 PHP/5.2.9
  133818 PHP/5.2.6
  125550 PHP/5.3.10
  109513 PHP/5.2.6-1+lenny13
  106320 PHP/5.2.5
  102412 PHP/5.2.14
   81221 PHP/5.2.6-1+lenny9

These are the top-10 most popular PHP 5.x versions out there.  PHP 5.4.x,
in case you're wondering, shows up on the 44th place, with a bit over 20K
deployments worldwide (5.4.11).
With yearly release cycles, we may make the lives of a few users more
enjoyable and with more rapid access to new features;  But for the vast
majority, we're actually making lives worse:

1. Framework  app developers can't really rely on new features anyway,
since nobody has those new versions installed.  Just two years ago -
aiming for PHP 5.3 seemed like a bold move for ZF2 and Sf2 - and that's
even though PHP 5.3 brought some revolutionary features to the mix (which
5.4 and 5.5 do not).  We've also heard the Wordpress way of thinking, and
we can assume that it'd take many years before other apps feel comfortable
requiring a higher version than 5.3.x as a prerequisite.
2. Users who want to stay secure have to constantly upgrade, since support
lifetimes have been trimmed down substantially (effectively, 3 years from
release;  and considering nobody upgrades on to an x.y.0 version, it's
typically way less than that).  We can already project that based on the
current frequency, people who install PHP 5.4 today will have less than
two years-worth of lifetime before they're forced to upgrade, or be left
unsupported.
3.  For the ecosystem in general, we're creating lots of fragmentation.

All in all, I think the people who like the yearly release cycle are first
and foremost bleeding edge individual developers, and not people who are a
part of larger projects, or that actually have to worry about production
apps working uninterrupted.

Finally some agreement with what I've been getting my head chewed off every time 
I bring it up! For the last couple of years ...

--
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] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

On Thu, Feb 28, 2013 at 11:21 AM, Zeev Suraski z...@zend.com wrote:

 I'm not sure how many people you've spoken to and what their profile is,
 but reality shows a very different picture:

 481004 PHP/5.2.17
  280342 PHP/5.3.8
  271156 PHP/5.2.6-1+lenny16
 146342 PHP/5.2.9
  133818 PHP/5.2.6
  125550 PHP/5.3.10
  109513 PHP/5.2.6-1+lenny13
  106320 PHP/5.2.5
  102412 PHP/5.2.14
   81221 PHP/5.2.6-1+lenny9

 These are the top-10 most popular PHP 5.x versions out there.  PHP 5.4.x,
 in case you're wondering, shows up on the 44th place, with a bit over 20K
 deployments worldwide (5.4.11).
 With yearly release cycles, we may make the lives of a few users more
 enjoyable and with more rapid access to new features;  But for the vast
 majority, we're actually making lives worse:

This is amazing how you take every single opportunity to bash the new
release process, forgetting all pro arguments that have been brought
in the last discussions.

Let me write them down again in (hopefully) a more understandable way:

1. smaller and more frequent releases are easier to manage, from a
core dev, QA, ISPs and applications/developers point of view. Those
are our targets, not pepsi drinkers (read: consumers, they don't even
care if php runs under the hood as long as the app runs)

2. 100% BC compatibility between x.y and x.y+1. This is what prevents
many ISPs and other mass hosting to update to newer PHP versions. They
don't test if it works or not, they simply don't update due (too
expensive in support and revert) to our past bad job on keeping BC.

3. Judging the result of this process when only one release so far has
been published is totally wrong.

Instead of fighting it, what's about Zend talking about it to its so
numerous customers? For a change.

 1. Framework  app developers can't really rely on new features anyway,
 since nobody has those new versions installed.  Just two years ago -
 aiming for PHP 5.3 seemed like a bold move for ZF2 and Sf2 - and that's
 even though PHP 5.3 brought some revolutionary features to the mix (which
 5.4 and 5.5 do not).  We've also heard the Wordpress way of thinking, and
 we can assume that it'd take many years before other apps feel comfortable
 requiring a higher version than 5.3.x as a prerequisite.

I have discussed with many WP devs (and the lead), they all agree that
this process is a good thing and will help WP to move forward. It does
not mean they will stop to support older versions but they will change
the recommended versions.


 2. Users who want to stay secure have to constantly upgrade, since support
 lifetimes have been trimmed down substantially (effectively, 3 years from
 release;  and considering nobody upgrades on to an x.y.0 version, it's
 typically way less than that).  We can already project that based on the
 current frequency, people who install PHP 5.4 today will have less than
 two years-worth of lifetime before they're forced to upgrade, or be left
 unsupported.

Again, 1st release done via through this process. Our users (not the
consumers of our users products) have to see that we keep our word,
about BC, quality etc.


 3.  For the ecosystem in general, we're creating lots of fragmentation.

No, we do not. 5.4 code runs under 5.5 smoothly. But we do not prevent
newer versions of applications or modules to rely on 5.5 features. I
am convinced that the update path will be faster in the next couple of
years. The only missing part now is the communication about it. I have
been communicating about it at all conferences I attended as speaker
(talks, keynotes, etc.). I did not see any single negative comments
about it, but only positive and very motivated feedback. While people
also said that they will wait to see if we keep our words (as I said
earlier).

 All in all, I think the people who like the yearly release cycle are first
 and foremost bleeding edge individual developers, and not people who are a
 part of larger projects, or that actually have to worry about production
 apps working uninterrupted.

Having the pros of both sides is exactly why this process has been
created. Having a release active for almost a decade is simply not
possible.

Let me say it again, stop arguing and begin to promote and explain it
to your customers. That will be much more helpful than trying to fight
it with all possible ways.

Thanks.

Cheers,
--
Pierre

@pierrejoye

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

 This is amazing how you take every single opportunity to bash the new
release
 process, forgetting all pro arguments that have been brought in the last
 discussions.

I'm not bashing it.  I think the process is good.  I'm saying the
frequency is wrong and doesn't suit the needs of most of our users.

 Let me write them down again in (hopefully) a more understandable way:

You didn't state anything I wasn't aware of before, and yet, I still think
that a yearly release cycle is roughly 2x too frequent from where we
should be.

Most users don't upgrade because they don't need the new features and
can't be bothered to upgrade.

There's no such thing as 100% downwards compatibility, and 5.5 will be no
different in that sense from previous versions.  Perhaps it'll be three
nines instead of two nines (99.9% vs. 99%), but every keyword, every bug
fix, every change in an error reporting level - can break apps and make an
upgrade process non smooth.  We're not going to be able to change people's
perception.

Frequent releases are less easy to manage from just about any point.
Their one and only advantage is delivering features to the userbase more
quickly, which begs the question whether they're eagerly waiting for such
features.

In terms of upgrades - you have to spend more time upgrading  testing.
In terms of off-the-shelf-apps - you need to invest more in testing more
versions.  In terms of QA - fewer releases means less time spent in
testing.

 Instead of fighting it, what's about Zend talking about it to its so
numerous
 customers? For a change.

Zend has nothing to do with it.  We can't wave a magic wand and change
people's perception, habits or preferences.  Both our customers and the
companies I get to meet don't view a yearly release cycle favorably (most
of them - some do).

 I have discussed with many WP devs (and the lead), they all agree that
this
 process is a good thing and will help WP to move forward. It does not
mean they
 will stop to support older versions but they will change the recommended
 versions.

Process != frequency.  Our process is good, our frequency isn't.

 No, we do not. 5.4 code runs under 5.5 smoothly.

5.3 code runs smoothly on 5.4 too (except for ancient code using features
that have been deprecated for many many years).  Incompats have been blown
out of proportion - in the same way I can assure you the few incompats
between 5.4 and 5.5 will be blown out of proportion.

 Let me say it again, stop arguing and begin to promote and explain it to
your
 customers.

I admire your self-confidence, you seem to have enough of it for a whole
battalion of developers, but it's complete unwarranted in this case (as
well as other cases in recent weeks).  I think you're promoting a bad
thing for PHP, not because our users are idiots or fail to understand the
amazing advantages of a yearly release cycle - but because it's just bad.

Zeev

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

hi Zeev,

On Thu, Feb 28, 2013 at 2:06 PM, Zeev Suraski z...@zend.com wrote:


 Most users don't upgrade because they don't need the new features and
 can't be bothered to upgrade.

 There's no such thing as 100% downwards compatibility, and 5.5 will be no
 different in that sense from previous versions.  Perhaps it'll be three
 nines instead of two nines (99.9% vs. 99%), but every keyword, every bug
 fix, every change in an error reporting level - can break apps and make an
 upgrade process non smooth.  We're not going to be able to change people's
 perception.

nitpicking. You know what I mean.

 I admire your self-confidence, you seem to have enough of it for a whole
 battalion of developers, but it's complete unwarranted in this case

I have to suggest to join me in the next conferences then. Like the
one I gave talks about this topic (DrupalCons, general PHP
conferences, dozen of UGs, companies conferences, etc.). And the
attendees are not the usual suspects you could find at some major US
conferences.

  (as well as other cases in recent weeks).

I suppose you refer to my comments about us being out of sync with our
user bases, let say you talk to part of our users and I do to another.
Amazingly most of the frameworks and apps lead developers think the
same have the same opinion, go figure.

 I think you're promoting a bad
 thing for PHP, not because our users are idiots or fail to understand the
 amazing advantages of a yearly release cycle - but because it's just bad.

I promote what I and the users I talk to believe to be a good thing.

Cheers,
--
Pierre

@pierrejoye

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

Zeev has an excellent point here, my own research shows that 5.4, a
year after release had somewhere in the 2% adoption rate. The major
reason being is the lack of a stable, production ready op-code cache.
To release 5.5 without a good solution for that problem, would not
make the situation better, if anything it would make it very
intimidating to users to jump 2-3 versions directly to 5.6. Thus
leaving us with a massive user base running legacy, unsupported
versions containing unresolved bugs and vulnerabilities. Something,
which I don't think would be a very good thing for the future of PHP.

Ultimately, I think it is better to wait a month or two (if that is
what it takes) and have a solid release people can safely upgrade
their production environments to, rather than strictly adhere to a set
release cycle and delivery a partial solution.

On Thu, Feb 28, 2013 at 5:21 AM, Zeev Suraski z...@zend.com wrote:
 -Original Message-
 From: Pierre Joye [mailto:pierre@gmail.com]
 Sent: Thursday, February 28, 2013 12:17 AM
 To: Rasmus Lerdorf
 Cc: Ferenc Kovacs; Zeev Suraski; PHP Developers Mailing List
 Subject: Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP
 distribution

 Now, about the yearly release, every single person I talked to love it
 and want us
 to keep with this cycle, as well as the more frequent bugs fixes
 releases. One
 thing we have to slightly change is to push too many new features in
 each of
 them, but we will get there.

 I'm not sure how many people you've spoken to and what their profile is,
 but reality shows a very different picture:

 481004 PHP/5.2.17
  280342 PHP/5.3.8
  271156 PHP/5.2.6-1+lenny16
 146342 PHP/5.2.9
  133818 PHP/5.2.6
  125550 PHP/5.3.10
  109513 PHP/5.2.6-1+lenny13
  106320 PHP/5.2.5
  102412 PHP/5.2.14
   81221 PHP/5.2.6-1+lenny9

 These are the top-10 most popular PHP 5.x versions out there.  PHP 5.4.x,
 in case you're wondering, shows up on the 44th place, with a bit over 20K
 deployments worldwide (5.4.11).
 With yearly release cycles, we may make the lives of a few users more
 enjoyable and with more rapid access to new features;  But for the vast
 majority, we're actually making lives worse:

 1. Framework  app developers can't really rely on new features anyway,
 since nobody has those new versions installed.  Just two years ago -
 aiming for PHP 5.3 seemed like a bold move for ZF2 and Sf2 - and that's
 even though PHP 5.3 brought some revolutionary features to the mix (which
 5.4 and 5.5 do not).  We've also heard the Wordpress way of thinking, and
 we can assume that it'd take many years before other apps feel comfortable
 requiring a higher version than 5.3.x as a prerequisite.
 2. Users who want to stay secure have to constantly upgrade, since support
 lifetimes have been trimmed down substantially (effectively, 3 years from
 release;  and considering nobody upgrades on to an x.y.0 version, it's
 typically way less than that).  We can already project that based on the
 current frequency, people who install PHP 5.4 today will have less than
 two years-worth of lifetime before they're forced to upgrade, or be left
 unsupported.
 3.  For the ecosystem in general, we're creating lots of fragmentation.

 All in all, I think the people who like the yearly release cycle are first
 and foremost bleeding edge individual developers, and not people who are a
 part of larger projects, or that actually have to worry about production
 apps working uninterrupted.

 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] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

Ilia,


On Thu, Feb 28, 2013 at 8:54 AM, Ilia Alshanetsky i...@prohost.org wrote:

 Zeev has an excellent point here, my own research shows that 5.4, a
 year after release had somewhere in the 2% adoption rate. The major
 reason being is the lack of a stable, production ready op-code cache.
 To release 5.5 without a good solution for that problem, would not
 make the situation better, if anything it would make it very
 intimidating to users to jump 2-3 versions directly to 5.6. Thus
 leaving us with a massive user base running legacy, unsupported
 versions containing unresolved bugs and vulnerabilities. Something,
 which I don't think would be a very good thing for the future of PHP.


To be fair, the 5.5 situation without pulling in ZO+ is NOT the same as 5.4
was. Today, right now, there exists at least one stable open source opcode
cache. 5.4 had none for many months after release. So I'm not sure if the
same pressures exist.

The discussion now is if we delay 5.5 to spend the time pulling it in core.
But either way (in core or not), ZO+ is open and working on 5.5 alpha. So
we could skip the core import, and just ship it today as gold, and it would
be adoptable straight away (unlike how 5.4 was).


 Ultimately, I think it is better to wait a month or two (if that is
 what it takes) and have a solid release people can safely upgrade
 their production environments to, rather than strictly adhere to a set
 release cycle and delivery a partial solution.


That's the thing though, it wouldn't be a partial solution. It would be
exactly where 5.2, 5.3 and 5.4 are today, with the addition of several
highly wanted features.

I'd rather delay 5.6, and do a deeper integration into the engine. Then at
least there's something to gain by pulling it into core, rather than just
having it be a compile-time-flag as opposed to a pecl installation (which
doesn't buy us *that* much)...

My standpoint at least...

Anthony

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

2013-02-28 Thread Jordi Boggiano

On 28.02.2013 11:47, Frank Schenk wrote:
 For our company stability and bug fixes are way more important (like
 10fold) than having fancy new features. I was asked, if we can switch to
 5.4.x but i refused, because it's a couple of days work for each project
 to evaluate and migrate to 5.4.x

I can see your point, but don't you think this is also an old
mentality that might need to be adjusted? What I mean is that with the
higher frequency of releases, and the more strict no-BC breaks
guidelines (many thanks to Pierre and others for doing your best to
enforce that btw..), upgrading becomes less dangerous since there are
less minor changes. I personally can't remember having any issues with
5.4 except for 5.4.0 breaking some odd things in file_get_contents, but
.0 releases are always too buggy to upgrade. I have also been developing
with 5.5 for a while now and did not notice anything out of the ordinary.

Cheers

-- 
Jordi Boggiano
@seldaek - http://nelm.io/jordi

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

2013-02-28 Thread Jan Ehrhardt

Jordi Boggiano in php.internals (Thu, 28 Feb 2013 15:33:06 +0100):
On 28.02.2013 11:47, Frank Schenk wrote:
For our company stability and bug fixes are way more important (like
10fold) than having fancy new features. I was asked, if we can switch to
5.4.x but i refused, because it's a couple of days work for each project
to evaluate and migrate to 5.4.x

I can see your point, but don't you think this is also an old
mentality that might need to be adjusted? What I mean is that with the
higher frequency of releases, and the more strict no-BC breaks
guidelines (many thanks to Pierre and others for doing your best to
enforce that btw..), upgrading becomes less dangerous since there are
less minor changes. I personally can't remember having any issues with
5.4 except for 5.4.0 breaking some odd things in file_get_contents, but
.0 releases are always too buggy to upgrade. I have also been developing
with 5.5 for a while now and did not notice anything out of the ordinary.

The life cycle of many frameworks is much longer than PHP's release
cycle. Just Google on 'drupal6 views PHP 5.4' and you will see that
there are 5.4 issues in one of the core modules in drupal 6. Example:
http://drupal.org/node/1833170

Workaround: turn off strict warnings. You do not want users to do that.
Or, other approach, filter PHP's error messages with regexs:
http://www.howtoeverything.net/linux/drupal/selectively-hide-strict-warning-errors-php-5.4-drupal-6.x-views

Jan

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

hi Ilia,

On Thu, Feb 28, 2013 at 2:54 PM, Ilia Alshanetsky i...@prohost.org wrote:
 Zeev has an excellent point here, my own research shows that 5.4, a
 year after release had somewhere in the 2% adoption rate. The major
 reason being is the lack of a stable, production ready op-code cache.
 To release 5.5 without a good solution for that problem, would not
 make the situation better, if anything it would make it very
 intimidating to users to jump 2-3 versions directly to 5.6. Thus
 leaving us with a massive user base running legacy, unsupported
 versions containing unresolved bugs and vulnerabilities. Something,
 which I don't think would be a very good thing for the future of PHP.

I do not oppose to have O+ in core. I am only opposed to have it right
now in 5.5 given the current state of its development, stability and
lack of pecl releases.

 Ultimately, I think it is better to wait a month or two (if that is
 what it takes) and have a solid release people can safely upgrade
 their production environments to, rather than strictly adhere to a set
 release cycle and delivery a partial solution.

All distributions will provide it as a separate package anyway. For
most of our users there will be zero difference if it is core with 5.5
or in pecl only (or both). As Anthony said earlier, doing our best to
get 5.5 out sooner rather than later and move to the next step for o+,
the actual integration (no, I do not refer to cleanup legacy code in
o+ but tight integration to the engine). That will actually bring a
lot more benefits to our users.

Cheers,
-- 
Pierre

@pierrejoye

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

 -Original Message-
 From: Pierre Joye [mailto:pierre@gmail.com]
 Sent: Thursday, February 28, 2013 3:12 PM
 To: Zeev Suraski
 Cc: Ferenc Kovacs; Rasmus Lerdorf; PHP Developers Mailing List
 Subject: Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP
 distribution

 hi Zeev,

 On Thu, Feb 28, 2013 at 2:06 PM, Zeev Suraski z...@zend.com wrote:

  Most users don't upgrade because they don't need the new features and
  can't be bothered to upgrade.

  There's no such thing as 100% downwards compatibility, and 5.5 will be
  no different in that sense from previous versions.  Perhaps it'll be
  three nines instead of two nines (99.9% vs. 99%), but every keyword,
  every bug fix, every change in an error reporting level - can break
  apps and make an upgrade process non smooth.  We're not going to be
  able to change people's perception.

 nitpicking. You know what I mean.

Of course I do, but I would say that saying 5.4 is 'extremely incompatible
with 5.3' is also nitpicking.  Which is why I doubt 5.5 will see
dramatically different adoption rates from 5.4.  If anything, having O+
inside 5.5 would help - although personally I think that the reason people
aren't upgrading to 5.4 isn't just the fact APC wasn't available.  It's
simply not a priority for them as earlier versions are already doing
everything they need, and if it ain't broke - don't fix it.

 I have to suggest to join me in the next conferences then. Like the one
I gave
 talks about this topic (DrupalCons, general PHP conferences, dozen of
UGs,
 companies conferences, etc.). And the attendees are not the usual
suspects you
 could find at some major US conferences.

The conferences you cite are very, very developer centric.  As weird as it
may sound - developers typically don't get to choose what version of PHP
they run on, beyond perhaps the initial setup.  Operations people do.  And
they won't install PHP 5.5 because Pierre tells them it's 100% compatible.
They'd need to (a) have a good reason to upgrade (b) have it prioritized
high enough over all the other things they need to do (c) have apps fully
tested before they roll a version out.  I, for one, wouldn't dream of
rolling out PHP 5.5 without fully testing that nothing broke, and I'm not
exactly a very conservative ops person.

 I suppose you refer to my comments about us being out of sync with our
user
 bases, let say you talk to part of our users and I do to another.

I refer to your lack of respect for pluralism, the fact that other people
may have a different opinion, and that possibility that you may simply not
be right.  Just in case it wasn't clear - I very much admit the
possibility that I may be wrong, and that the yearly cycle is a good
thing.  Everything I know about how PHP is actually being used in
production tells me otherwise, but you're not going to hear something
along the lines of it's not my opinion but a simple fact, even if though
I very strongly believe in what I say.

 Amazingly most of the frameworks and apps lead developers think the same
 have the same opinion, go figure.

If 5.3 was any indication, then the leaders of the two biggest frameworks
barely made the decision to switch to PHP 5.3 almost a full year after it
came out, and that's just as they were gearing up to *start* developing.
Drupal 8, that just came out - doesn't take advantage of PHP 5.4 features,
and only discontinued support for PHP 5.2.  WP still supports 5.2, and
therefore doesn't even take advantage of PHP 5.3 features.  The list goes
on.

Could it be that you're just a tad bit too self-confident with the yearly
release cycle?  I know you'd say 'no', the question is directed to others
reading this message.

Zeev

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

2013-02-28 Thread Lester Caine


Zeev Suraski wrote:

Of course I do, but I would say that saying 5.4 is 'extremely incompatible
with 5.3' is also nitpicking.  Which is why I doubt 5.5 will see
dramatically different adoption rates from 5.4.  If anything, having O+
inside 5.5 would help - although personally I think that the reason people
aren't upgrading to 5.4 isn't just the fact APC wasn't available.  It's
simply not a priority for them as earlier versions are already doing
everything they need, and if it ain't broke - don't fix it.


Code which originated in pre 5.3 days and has had the faults hidden when running 
on 5.3 still needs work to run on 5.4. If the faults were fixed in 5.3, then 
it's more likely to run on 5.4 even with e_strict off. I have yet to get a 
legacy site that does not need a few hours work to get it running again in 5.4. 
I've still another 60 odd to work through and some of them still use things 
removed in 5.4. The hassle with ?= stopping working is a good example of the 
sort of thing which affects confidence in upgrading!


The reality is that one simply can't switch existing code between versions of 
PHP without first checking it, and checking every site take time. We are having 
to test on 5.3 because that is what ISP's are moving to, while it would be nice 
simply to skip that step and go straight to 5.4. Having moved to 5.3 then it 
still leaves a question - do you switch on the hidden stuff and see if it can be 
tidied up? It's finding the time to clean up all of the hidden warnings that is 
the killer :(


Finding time to test everything again in 5.5 is simply not going to happen this 
end, and I'm more than happy with eaccelerator in production. Everything is 
running stability so why should I be wasting all this time anyway? The paying 
customers simply expect their sites to work ...


--
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] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

2013-02-28 Thread Nikita Popov

On Wed, Feb 27, 2013 at 5:12 PM, Zeev Suraski z...@zend.com wrote:

 Based on the overwhelming response, the vote is now open J



 https://wiki.php.net/rfc/optimizerplus



 Voting ends March 7th.


What kind of majority does this vote require? 50% or 2/3?

Thanks,
Nikita

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

No syntax changes, so regular majority as far as I can tell.

Sent from my mobile

On 28 בפבר 2013, at 19:33, Nikita Popov nikita@gmail.com wrote:

On Wed, Feb 27, 2013 at 5:12 PM, Zeev Suraski z...@zend.com wrote:

 Based on the overwhelming response, the vote is now open J



 https://wiki.php.net/rfc/optimizerplus



 Voting ends March 7th.


What kind of majority does this vote require? 50% or 2/3?

Thanks,
Nikita

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

On Thu, Feb 28, 2013 at 6:35 PM, Zeev Suraski z...@zend.com wrote:
 No syntax changes, so regular majority as far as I can tell.

Except if you want real integration included in this vote, as it will
or may affect the engine, 2/3 will be required then.

-- 
Pierre

@pierrejoye

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

No.

First, read what 'integration' means in the RFC or in the excerpt
Chris was nice enough to send you.  It means including the extension,
which doesn't fall under changing the language in the voting RFC in
any way.

Secondly, even ifwhen we do propose to integrate it more tightly -
it's debatable whether it constitutes a language change that requires
a 2/3 majority.  Even though I'm sure that if we manage to show
substantial benefits from doing that in the future well get a lot more
than 67% in favor...

- Sent from my mobile

On 28 בפבר 2013, at 19:40, Pierre Joye pierre@gmail.com wrote:

 On Thu, Feb 28, 2013 at 6:35 PM, Zeev Suraski z...@zend.com wrote:
 No syntax changes, so regular majority as far as I can tell.

 Except if you want real integration included in this vote, as it will
 or may affect the engine, 2/3 will be required then.

 --
 Pierre

 @pierrejoye

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

On Thu, Feb 28, 2013 at 6:58 PM, Zeev Suraski z...@zend.com wrote:
 No.

 First, read what 'integration' means in the RFC or in the excerpt
 Chris was nice enough to send you.  It means including the extension,
 which doesn't fall under changing the language in the voting RFC in
 any way.

That's not integration, that's bundling with some cleanups. Let call a
cat a cat.

 Secondly, even ifwhen we do propose to integrate it more tightly -
 it's debatable whether it constitutes a language change that requires
 a 2/3 majority.  Even though I'm sure that if we manage to show
 substantial benefits from doing that in the future well get a lot more
 than 67% in favor...

Please do not get me wrong, I was the 1st to propose a tight
integration in a 2nd phase, and to push as much resources as we can to
get o+ tested and ready in time. However it does not mean that I can
or will simply say yes to any kind of move just because an opcode
cache being bundled is uber sexy. It is, but that's not a small step
and that's something that has to be done the right way, by all means.

About debating if something is tightly integrated or enabled by
default, phar is one of the examples causing issues even if one does
not use it. To think about having a similar case at the engine level
is not something I want to take softly but carefully.

On a good news side, recent fixes solved a couple of issues we got
during testing (thanks Dmitry). One critical remains, Matt will post a
summary later today.


Cheers,
-- 
Pierre

@pierrejoye

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

2013-02-28 Thread Nikita Popov

On Thu, Feb 28, 2013 at 6:35 PM, Zeev Suraski z...@zend.com wrote:

 No syntax changes, so regular majority as far as I can tell.

 Sent from my mobile


It's not a syntax change, but it is a very, very large engine change. Yes,
it does not touch the Zend engine itself, but it adds a large amount of new
code that is close to the engine. People doing engine changes will need to
modify it too (thus it is quasi part of the engine, even if it lives in a
separate directory). All existing core devs will have to study and
understand the code. All new developers have an additional piece of very
complex code to study before they can start making core changes.

So no, this is not a syntax change, but it is a engine change with a by
*far* larger impact than any of the other things that have been introduced
in PHP 5.5 (like generators or finally).

That's why I asked about the type of vote. I'm never quite sure which kind
of vote something requires (maybe we could clarify that paragraph in the
voting RFC a bit?)

Thanks, Nikita

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

2013-02-28 Thread Rasmus Lerdorf

On 02/28/2013 10:37 AM, Nikita Popov wrote:
 On Thu, Feb 28, 2013 at 6:35 PM, Zeev Suraski z...@zend.com wrote:
 
 No syntax changes, so regular majority as far as I can tell.

 Sent from my mobile

 
 It's not a syntax change, but it is a very, very large engine change. Yes,
 it does not touch the Zend engine itself, but it adds a large amount of new
 code that is close to the engine. People doing engine changes will need to
 modify it too (thus it is quasi part of the engine, even if it lives in a
 separate directory). All existing core devs will have to study and
 understand the code. All new developers have an additional piece of very
 complex code to study before they can start making core changes.

Which arguable core devs should have been doing for years but weren't.
The issues you need to be aware of with ZO+ aren't any different from
what you need to be aware of with any opcode cache and that has been the
cause of the big lag between new PHP releases and support from opcode
caches. Getting everyone on the same page with a single de-facto
standard opcode cache is going to be a huge win and the sooner we can
get there, the better.

-Rasmus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

2013-02-28 Thread Raymond Irving

I'm very sure users will not complain if 5.5 is delayed for a few months.
Most websites will not be installing 5.5 immediately after it has been
released.

My take on this is that we integrate O+ in to core, iron out all the issues
and then release  a stable 5.5.

If O+ will improve the performance of PHP then I'm sure users will love it.

__
Raymond


On Thu, Feb 28, 2013 at 1:37 PM, Nikita Popov nikita@gmail.com wrote:

 On Thu, Feb 28, 2013 at 6:35 PM, Zeev Suraski z...@zend.com wrote:

  No syntax changes, so regular majority as far as I can tell.
 
  Sent from my mobile
 

 It's not a syntax change, but it is a very, very large engine change. Yes,
 it does not touch the Zend engine itself, but it adds a large amount of new
 code that is close to the engine. People doing engine changes will need to
 modify it too (thus it is quasi part of the engine, even if it lives in a
 separate directory). All existing core devs will have to study and
 understand the code. All new developers have an additional piece of very
 complex code to study before they can start making core changes.

 So no, this is not a syntax change, but it is a engine change with a by
 *far* larger impact than any of the other things that have been introduced
 in PHP 5.5 (like generators or finally).

 That's why I asked about the type of vote. I'm never quite sure which kind
 of vote something requires (maybe we could clarify that paragraph in the
 voting RFC a bit?)

 Thanks, Nikita

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

 To be fair, the 5.5 situation without pulling in ZO+ is NOT the same as 5.4
 was. Today, right now, there exists at least one stable open source opcode
 cache. 5.4 had none for many months after release. So I'm not sure if the
 same pressures exist.

If you are referring to APC as the stable cache, that unfortunately is
not entirely correct, it is still relatively easy to crash APC unless
some work-arounds are applied. I was speaking to a several people at
the conference just yesterday and they were indicating frequent
crashes with APC, the work-arounds appear to have solved their issues,
but those are not exactly obvious.

 The discussion now is if we delay 5.5 to spend the time pulling it in core.
 But either way (in core or not), ZO+ is open and working on 5.5 alpha. So we
 could skip the core import, and just ship it today as gold, and it would be
 adoptable straight away (unlike how 5.4 was).

Well the question around the delay, is what is the negative
consequence of the delay, versus the advantage of having a built-in
opcode cache shipped as part of 5.5 which is likely to give many
people an impetuous to upgrade from their current 5.2/5.3 install.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

On Feb 28, 2013 7:56 PM, Ilia Alshanetsky i...@prohost.org wrote:


Well the question around the delay, is what is the negative
 consequence of the delay, versus the advantage of having a built-in
 opcode cache shipped as part of 5.5 which is likely to give many
 people an impetuous to upgrade from their current 5.2/5.3 install.

If we get to get it stable in a relatively short period. It is hard with
APC, which is available open since its very 1st day, it is harder with o+,
new code, new algos, new settings, etc.

Pierre

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

Hi!

 It's not a syntax change, but it is a very, very large engine change. Yes,
 it does not touch the Zend engine itself, but it adds a large amount of new
 code that is close to the engine. People doing engine changes will need to
 modify it too (thus it is quasi part of the engine, even if it lives in a

I'm not sure how it makes sense - people changing the engine had to
modify SPL or libxml or SOAP extension, for example - so now SOAP is
part of the engine? Since engine is underlying API, if you modify the
engine then you may have to modify extensions, doesn't mean all
extensions are part of the engine. I find this pretty strained argument.

 separate directory). All existing core devs will have to study and
 understand the code. All new developers have an additional piece of very
 complex code to study before they can start making core changes.

Again, by this logic everything is the engine - if you didn't look at
how PDO works and changed the engine in a way that broke PDO - it's bad,
so by that logic PDO is the engine. And so is pretty much any extension
anybody cares about.

-- 
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] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

Ilia,


If you are referring to APC as the stable cache, that unfortunately is
 not entirely correct, it is still relatively easy to crash APC unless
 some work-arounds are applied. I was speaking to a several people at
 the conference just yesterday and they were indicating frequent
 crashes with APC, the work-arounds appear to have solved their issues,
 but those are not exactly obvious.


Even more evidence that the situation for 5.5 is not the same as for 5.4,
as a stable cache does exist for 5.5, when it still doesn't for 5.4...

But either way:


  The discussion now is if we delay 5.5 to spend the time pulling it in
 core.
  But either way (in core or not), ZO+ is open and working on 5.5 alpha.
 So we
  could skip the core import, and just ship it today as gold, and it would
 be
  adoptable straight away (unlike how 5.4 was).

 Well the question around the delay, is what is the negative
 consequence of the delay, versus the advantage of having a built-in
 opcode cache shipped as part of 5.5 which is likely to give many
 people an impetuous to upgrade from their current 5.2/5.3 install.


What advantage do we get by doing a surface level inclusion? We're not
going to refactor the engine for 5.5. We're not going to do any deep
integrations in 5.5 (or as the RFC puts it, soft integrations). So what
is the advantage of inclusion?

From my eyes, the only advantage for a soft integration is the fact that
the source code is bundled. It wouldn't be enabled by default (which is
VERY ambiguous from the RFC). It wouldn't provide ANY benefit from it being
in PECL with the exception that the source code ships together with core...

What is the disadvantage to bringing it in 5.5? Well, there are a few:

1. We're holding up the 5.5 release indefinitely. Meaning that we're not
time-boxed as the RFC process intends the release to be, but instead we're
feature boxed. What happens if we approve this for 5.5, and in two weeks
everyone working on it decides to go on vacation for two years. We're stuck
in the same boat as we are with 6. We promised and agreed to do something,
but for whatever reason didn't. That's EXACTLY what this time-boxed RFC
process does. It prevents that from happening.

2. We've already delayed 5.5 by a month. When Zeev first offered to open
source it, the message presented then was that it would be out in a few
days (end of week I think was the original message), and it would only take
a few days from there to integrate. Now we're a month later, and the source
was just made available 1 week ago. Two weeks later than promised. And it's
looking like an additional several months of work to integrate. I'm deeply
concerned that oh it should only take 2 months to fix up could very
easily turn into a LOT longer of a time... Which would be bad for everyone.

3. It's sending the wrong message. We have policies and procedures for a
reason. Now, I have no issue with having a deviation policy that allows us
to deviate, but let's be smart about the deviations. Doing a deviation here
basically says the whole release process is bad, and we can do whatever we
want whenever we want as long as it's popular. That's not why we agree on
policies and procedures...

My thoughts at least...

Anthony

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

Well the question around the delay, is what is the negative
 consequence of the delay, versus the advantage of having a built-in
 opcode cache shipped as part of 5.5 which is likely to give many
 people an impetuous to upgrade from their current 5.2/5.3 install.

 If we get to get it stable in a relatively short period. It is hard with
 APC, which is available open since its very 1st day, it is harder with o+,
 new code, new algos, new settings, etc.

If ZO+ was a brand new code, I'd agree with you 100%. However, it is
an existing solution that has been used in a wild in quite some time
an limited empirical evidence shows that it works somewhat better than
APC in most cases from stability perspective.

Ultimately, peoples opinions will drive the decision, just wanted to
share my perspective based on personal experience and feedback that I
got from people trying to use 5.4 in production and their expressed
pains...

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

Hi!

 If you are referring to APC as the stable cache, that unfortunately is
 not entirely correct, it is still relatively easy to crash APC unless
 some work-arounds are applied. I was speaking to a several people at
 the conference just yesterday and they were indicating frequent
 crashes with APC, the work-arounds appear to have solved their issues,
 but those are not exactly obvious.

Do we have those ways and work-arounds recorded somewhere? It would be a
very good idea to have tests for O+ to ensure there are no problems in
these areas (or if there are, to fix them :). My experience suggests
opcode cache solutions often tend to have issues in the same areas, so I
think it'd be very useful.

-- 
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] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

 If you are referring to APC as the stable cache, that unfortunately is
 not entirely correct, it is still relatively easy to crash APC unless
 some work-arounds are applied. I was speaking to a several people at
 the conference just yesterday and they were indicating frequent
 crashes with APC, the work-arounds appear to have solved their issues,
 but those are not exactly obvious.


 Even more evidence that the situation for 5.5 is not the same as for 5.4, as
 a stable cache does exist for 5.5, when it still doesn't for 5.4...

Wouldn't that make it ever so important to address this issue before
releasing another version, since production use of PHP pretty much
requires use of an opcode cache if you want any degree of performance?

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

The APC issues are somewhat APC specific in most cases, they often
revolve around memory utilization issues and garbage collection. Some
of the work-arounds involve ensuring APC always has extra memory to
prevent fragmentation. When fragmentation goes about 35-40% clearing
out the entire cache to prevent increase in fragmentation which in
many cases can reduce stability.

Loading large number of files in parallel is another thing that
frequently can negatively impact APC, doing pre-loading or staggering
the loading process is the work-around that typically prevents issues.

On Thu, Feb 28, 2013 at 2:16 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
 Hi!

 If you are referring to APC as the stable cache, that unfortunately is
 not entirely correct, it is still relatively easy to crash APC unless
 some work-arounds are applied. I was speaking to a several people at
 the conference just yesterday and they were indicating frequent
 crashes with APC, the work-arounds appear to have solved their issues,
 but those are not exactly obvious.

 Do we have those ways and work-arounds recorded somewhere? It would be a
 very good idea to have tests for O+ to ensure there are no problems in
 these areas (or if there are, to fix them :). My experience suggests
 opcode cache solutions often tend to have issues in the same areas, so I
 think it'd be very useful.

 --
 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] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

2013-02-28 Thread Nikita Popov

On Thu, Feb 28, 2013 at 8:13 PM, Stas Malyshev smalys...@sugarcrm.comwrote:

 Hi!

  It's not a syntax change, but it is a very, very large engine change.
 Yes,
  it does not touch the Zend engine itself, but it adds a large amount of
 new
  code that is close to the engine. People doing engine changes will need
 to
  modify it too (thus it is quasi part of the engine, even if it lives in a

 I'm not sure how it makes sense - people changing the engine had to
 modify SPL or libxml or SOAP extension, for example - so now SOAP is
 part of the engine? Since engine is underlying API, if you modify the
 engine then you may have to modify extensions, doesn't mean all
 extensions are part of the engine. I find this pretty strained argument.


The difference between SOAP and ZO+ is the level of integration and
dependency. If you do a change in the ZE there is a very high chance that
you will not have to touch any code in SOAP, but you will quite likely need
to adjust something in ZO+. Phar is the only of the current extensions that
comes anywhere close to this. And ZO+ is still a *lot* more tightly
integrated than Phar (and you know what a PITA Phar can be...)

If you don't see that ZO+ is an extension that is very tightly integrated
with the ZE and rather sensitive to change, then sorry, can't help you. To
me this seems obvious.

Nikita

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

Zeev,

No syntax changes, so regular majority as far as I can tell.


However, it does nuke several existing PECL extensions (some fatally). For
example, XDebug has no compatibility with ZendOptimizer+ right now (at
least that I could find, feel free to correct me if I'm wrong here).

And some could argue that shipping with a modification that breaks known
and widely relied upon (if only for development) extensions would fit into
this category.

Since it changes the *functionality* that extensions experience
(specifically engine extensions), it should be considered an engine
change... The API doesn't change at the syntax level, but the contract
definitely does (preconditions, post conditions and invariants)...

Anthony

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

2013-02-28 Thread Derick Rethans

On Thu, 28 Feb 2013, Anthony Ferrara wrote:

 However, it does nuke several existing PECL extensions (some fatally). 
 For example, XDebug has no compatibility with ZendOptimizer+ right now 
 (at least that I could find, feel free to correct me if I'm wrong 
 here).

You wouldn't want to run them at the same time anyway... but we do need 
to have a look at this as APC+Xdebug worked just fine™

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] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

Hi!

 However, it does nuke several existing PECL extensions (some fatally). For
 example, XDebug has no compatibility with ZendOptimizer+ right now (at
 least that I could find, feel free to correct me if I'm wrong here).

This of course will have to be fixed before the release. Though right
now I don't see much reason why xdebug would break - did you try it and
if so what happened?
-- 
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] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

It shouldn't kill any PECL extensions, most certainly not Xdebug.

Ideally I'd like to get Xdebug compatibility for 5.5 - but even if we can't
make it - there's truth to the assertion you wouldn't want them both at the
same time.

Either way - in the long run O+ and Xdebug will *definitely* work together,
and in the short run, you can choose one or the other.  Also, I think
Rasmus said the combo works for him if he loads O+ first and Xdebug later,
so it may not be completely broken at all.  Fwiw, the code it takes to have
Zend Debugger work alongside O+ isn't very complicated and therefore I'm
not at all worried that we'll have a hard time supporting Xdebug.  As the
RFC states - that may require some minor engine changes.

Sent from my tablet

On 28 בפבר 2013, at 21:34, Anthony Ferrara ircmax...@gmail.com wrote:

Zeev,

No syntax changes, so regular majority as far as I can tell.


However, it does nuke several existing PECL extensions (some fatally). For
example, XDebug has no compatibility with ZendOptimizer+ right now (at
least that I could find, feel free to correct me if I'm wrong here).

And some could argue that shipping with a modification that breaks known
and widely relied upon (if only for development) extensions would fit into
this category.

Since it changes the *functionality* that extensions experience
(specifically engine extensions), it should be considered an engine
change... The API doesn't change at the syntax level, but the contract
definitely does (preconditions, post conditions and invariants)...

Anthony

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

2013-02-28 Thread Rasmus Lerdorf

On 02/28/2013 11:34 AM, Anthony Ferrara wrote:
 Zeev,
 
 No syntax changes, so regular majority as far as I can tell.
 
 
 However, it does nuke several existing PECL extensions (some fatally). For
 example, XDebug has no compatibility with ZendOptimizer+ right now (at
 least that I could find, feel free to correct me if I'm wrong here).

It works fine. You just have to load ZO before xdebug. If you load it
the other way around bad things happen. This wrong load order currently
happens if you toss it in your config file path dir and rely on the
alphabetical load order which is another reason to not have this thing
start with a 'z'.

 And some could argue that shipping with a modification that breaks known
 and widely relied upon (if only for development) extensions would fit into
 this category.

Since the fix for this is trivial, I think this isn't a valid concern.

-Rasmus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

Hi!

 It works fine. You just have to load ZO before xdebug. If you load it
 the other way around bad things happen. This wrong load order currently

Could you describe the bad things? Maybe we could have some checks in
either of them to prevent it... Of course, we could probably make ZO
just check if xdebug is loaded and react accordingly, but maybe we could
resolve it in a more elegant way...

-- 
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] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

2013-02-28 Thread Rasmus Lerdorf

On 02/28/2013 12:49 PM, Stas Malyshev wrote:
 Hi!
 
 It works fine. You just have to load ZO before xdebug. If you load it
 the other way around bad things happen. This wrong load order currently
 
 Could you describe the bad things? Maybe we could have some checks in
 either of them to prevent it... Of course, we could probably make ZO
 just check if xdebug is loaded and react accordingly, but maybe we could
 resolve it in a more elegant way...
 

Well, I did describe it back on Feb.13 and cc'ed you actually, but it
was a segfault which looked to be caused by a double-free in a piece of
complicated code. It manifested itself on line 203 of this code:

200 } else {
201 list($v, $selector) =
202 $this-variantFromURL($userID) ?:
203 $this-variantForUser($userID) ?:
204 $this-variantForGroup($userID) ?:
205 $this-variantForAdmin($userID) ?:
206 $this-variantForInternal() ?:
207 $this-variantByPercentage($bucketingID) ?:
208 array(self::OFF, 'w');

which, granted, is short-circuited-ternary-abuse, but still. Switching
the ZO/Xdebug load order cleared it up. It didn't happen on every
request and not on a stripped down test case, so it was hard to narrow
down further. But this is often the case for opcode cache-related problems.

The segfault looked like this:

#0  0x7fc5e636b6b1 in _zval_dtor_func (zvalue=0x7fc5ee784828) at
/home/rlerdorf/php-src/Zend/zend_variables.c:54
54  Z_OBJ_HT_P(zvalue)-del_ref(zvalue 
TSRMLS_CC);
(gdb) bt
#0  0x7fc5e636b6b1 in _zval_dtor_func (zvalue=0x7fc5ee784828) at
/home/rlerdorf/php-src/Zend/zend_variables.c:54
#1  0x7fc5e639f146 in _zval_dtor (execute_data=0x7fc5ebcd3da8) at
/home/rlerdorf/php-src/Zend/zend_variables.h:35
#2  i_zval_ptr_dtor (execute_data=0x7fc5ebcd3da8) at
/home/rlerdorf/php-src/Zend/zend_execute.h:87
#3  zend_leave_helper_SPEC (execute_data=0x7fc5ebcd3da8) at
/home/rlerdorf/php-src/Zend/zend_vm_execute.h:468
#4  0x7fc5e63d4cb0 in execute (op_array=0x7fc5ee6d4140) at
/home/rlerdorf/php-src/Zend/zend_vm_execute.h:410
#5  0x7fc5e26289c9 in xdebug_execute (op_array=0x7fc5ee6d4140) at
/home/rlerdorf/pecl/xdebug/xdebug.c:1435
#6  0x7fc5e63e7bf1 in zend_do_fcall_common_helper_SPEC
(execute_data=value optimized out)
at /home/rlerdorf/php-src/Zend/zend_vm_execute.h:669
#7  0x7fc5e63d4cb0 in execute (op_array=0x7fc5ee6cd918) at
/home/rlerdorf/php-src/Zend/zend_vm_execute.h:410
#8  0x7fc5e26289c9 in xdebug_execute (op_array=0x7fc5ee6cd918) at
/home/rlerdorf/pecl/xdebug/xdebug.c:1435
#9  0x7fc5e63e7bf1 in zend_do_fcall_common_helper_SPEC
(execute_data=value optimized out)
at /home/rlerdorf/php-src/Zend/zend_vm_execute.h:669
#10 0x7fc5e63d4cb0 in execute (op_array=0x7fc5ee6c9d98) at
/home/rlerdorf/php-src/Zend/zend_vm_execute.h:410
#11 0x7fc5e26289c9 in xdebug_execute (op_array=0x7fc5ee6c9d98) at
/home/rlerdorf/pecl/xdebug/xdebug.c:1435
#12 0x7fc5e63e7bf1 in zend_do_fcall_common_helper_SPEC
(execute_data=value optimized out)
at /home/rlerdorf/php-src/Zend/zend_vm_execute.h:669
#13 0x7fc5e63d4cb0 in execute (op_array=0x7fc5ee6c5240) at
/home/rlerdorf/php-src/Zend/zend_vm_execute.h:410
#14 0x7fc5e26289c9 in xdebug_execute (op_array=0x7fc5ee6c5240) at
/home/rlerdorf/pecl/xdebug/xdebug.c:1435
#15 0x7fc5e63e7bf1 in zend_do_fcall_common_helper_SPEC
(execute_data=value optimized out)
at /home/rlerdorf/php-src/Zend/zend_vm_execute.h:669
#16 0x7fc5e63d4cb0 in execute (op_array=0x7fc5ee2b4868) at
/home/rlerdorf/php-src/Zend/zend_vm_execute.h:410
#17 0x7fc5e26289c9 in xdebug_execute (op_array=0x7fc5ee2b4868) at
/home/rlerdorf/pecl/xdebug/xdebug.c:1435
#18 0x7fc5e63e7bf1 in zend_do_fcall_common_helper_SPEC
(execute_data=value optimized out)
at /home/rlerdorf/php-src/Zend/zend_vm_execute.h:669
#19 0x7fc5e63d4cb0 in execute (op_array=0x7fc5ee713800) at
/home/rlerdorf/php-src/Zend/zend_vm_execute.h:410
#20 0x7fc5e26289c9 in xdebug_execute (op_array=0x7fc5ee713800) at
/home/rlerdorf/pecl/xdebug/xdebug.c:1435
#21 0x7fc5e63e7bf1 in zend_do_fcall_common_helper_SPEC
(execute_data=value optimized out)
at /home/rlerdorf/php-src/Zend/zend_vm_execute.h:669
#22 0x7fc5e63d4cb0 in execute (op_array=0x7fc5ee6f7e20) at
/home/rlerdorf/php-src/Zend/zend_vm_execute.h:410
#23 0x7fc5e26289c9 in xdebug_execute (op_array=0x7fc5ee6f7e20) at
/home/rlerdorf/pecl/xdebug/xdebug.c:1435
#24 0x7fc5e63e7bf1 in zend_do_fcall_common_helper_SPEC
(execute_data=value optimized out)
at /home/rlerdorf/php-src/Zend/zend_vm_execute.h:669
#25 0x7fc5e63d4cb0 in execute (op_array=0x7fc5ee6f5e50) at
/home/rlerdorf/php-src/Zend/zend_vm_execute.h:410
#26 0x7fc5e26289c9 in xdebug_execute (op_array=0x7fc5ee6f5e50) at
/home/rlerdorf/pecl/xdebug/xdebug.c:1435
#27

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

On Thu, Feb 28, 2013 at 10:27 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
 On 02/28/2013 11:34 AM, Anthony Ferrara wrote:
 Zeev,

 No syntax changes, so regular majority as far as I can tell.


 However, it does nuke several existing PECL extensions (some fatally). For
 example, XDebug has no compatibility with ZendOptimizer+ right now (at
 least that I could find, feel free to correct me if I'm wrong here).

 It works fine. You just have to load ZO before xdebug. If you load it
 the other way around bad things happen. This wrong load order currently
 happens if you toss it in your config file path dir and rely on the
 alphabetical load order which is another reason to not have this thing
 start with a 'z'.

 And some could argue that shipping with a modification that breaks known
 and widely relied upon (if only for development) extensions would fit into
 this category.

 Since the fix for this is trivial, I think this isn't a valid concern.

 -Rasmus


Hello php.internals,


I've read all the e-mails so far and there are valid points from both
parts but it seems there's a critical thing missing.

What do PHP users want?

I mean, what do sysadmins, programmers and managers want from PHP 5.5?

Here's my personal opinion:

I work in an enterprise so... I want stability (includes bug fixes)
and speed. In this order. Language features are on the third spot, at
least this is the case for PHP 5.5.

We'll get generators and a function for passwords and something I
really don't care about :) Why? Because I won't have a chance to use
them soon and by the time I'll use them PHP will get to version 5.8
most likely. So for me the fact that PHP 5.5 will be delayed a couple
of months is irrelevant.

We upgrade either to use better tools/frameworks or to benefit from
security patches when versions are no longer maintained so unless
something big appears earlier there's no point to upgrade.

Don't get me wrong, those features are great, as much as those in PHP
5.4, yet history tells us that people still didn't made that step to
upgrade to 5.4 yet.

So if those features are not that 'something big' then what is it?

A huge, out of the box, speed bump for production machines.

Could this be done with APC? Most likely, that is if a stable APC were
to be released same time as PHP 5.5. I really don't want to offend
anyone but see what happened with 5.4 and APC.

What I'm trying to say is: if O+ can be added to PHP 5.5 and made
stable, and I do mean production ready which from my understanding is
almost there, then why shouldn't it be done?

But I'm just a single user. Maybe I'm right, maybe I'm wrong. But so
are the other people who replied here so far, they are all only
individuals.

This is a perfect opportunity for testing out the whole: 'ask your
users' thing that me and several other people were talking about.

How expensive would it be, both in time and actual costs, to actually
make this happen? Either setup a poll on php.net or on a third party
service for one-two weeks and ask the users these simple questions
(obviously they could be better, POC ahead):

What do you expect from PHP 5.5? (multiple choice)
- better security
- better stability
- better speed
- more language features
- other type here
- all of the above

Do you know what an opcode cache is?
- yes
- no

Would you be ok if PHP 5.5 will not ship in April 2013 but in August
2013 because we want to integrate an opcode cache, a functionality,
which once used could increase the speed of your applications by up to
50% or more*?
- yes
- no

* NOTE: the speed increase is not guaranteed to be the same for all
applications nor it is guaranteed.

Would the fact that PHP 5.5 doesn't ship as originally planed, if the
mentioned integration happens, affect your view about PHP?
- yes
- no

What position do you have in your company?
- developer
- sysadmin
- devops
- manager
- other: type here

Are you in a position to influence the upgrade from your current PHP
version to PHP 5.5?
- yes
- no


Afaik every major framework has someone here, on the ML, then we have
Zend and we have some other libraries and so on here as well. Imagine
if all those people would link from their websites to the said poll. I
think it would be a small effort from them but the responses could at
least point out to what users actually want and help you in sorting
this out.

If I offended anyone, which I'm almost sure I did, it was not my
intention, please forgive me.

Thank you all for your hard work on PHP.



Best regards.

Florin Patan
https://github.com/dlsniper

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

 I've read all the e-mails so far and there are valid points from both
 parts but it seems there's a critical thing missing.

 What do PHP users want?

 I mean, what do sysadmins, programmers and managers want from PHP 5.5?

 Here's my personal opinion:

 I work in an enterprise so... I want stability (includes bug fixes)
 and speed. In this order. Language features are on the third spot, at
 least this is the case for PHP 5.5.

 We'll get generators and a function for passwords and something I
 really don't care about :) Why? Because I won't have a chance to use
 them soon and by the time I'll use them PHP will get to version 5.8
 most likely. So for me the fact that PHP 5.5 will be delayed a couple
 of months is irrelevant.

 We upgrade either to use better tools/frameworks or to benefit from
 security patches when versions are no longer maintained so unless
 something big appears earlier there's no point to upgrade.

 Don't get me wrong, those features are great, as much as those in PHP
 5.4, yet history tells us that people still didn't made that step to
 upgrade to 5.4 yet.

 So if those features are not that 'something big' then what is it?

 A huge, out of the box, speed bump for production machines.

 Could this be done with APC? Most likely, that is if a stable APC were
 to be released same time as PHP 5.5. I really don't want to offend
 anyone but see what happened with 5.4 and APC.

 What I'm trying to say is: if O+ can be added to PHP 5.5 and made
 stable, and I do mean production ready which from my understanding is
 almost there, then why shouldn't it be done?

 But I'm just a single user. Maybe I'm right, maybe I'm wrong. But so
 are the other people who replied here so far, they are all only
 individuals.

 This is a perfect opportunity for testing out the whole: 'ask your
 users' thing that me and several other people were talking about.

 How expensive would it be, both in time and actual costs, to actually
 make this happen? Either setup a poll on php.net or on a third party
 service for one-two weeks and ask the users these simple questions
 (obviously they could be better, POC ahead):

 What do you expect from PHP 5.5? (multiple choice)
 - better security
 - better stability
 - better speed
 - more language features
 - other type here
 - all of the above

 Do you know what an opcode cache is?
 - yes
 - no

 Would you be ok if PHP 5.5 will not ship in April 2013 but in August
 2013 because we want to integrate an opcode cache, a functionality,
 which once used could increase the speed of your applications by up to
 50% or more*?
 - yes
 - no

 * NOTE: the speed increase is not guaranteed to be the same for all
 applications nor it is guaranteed.

 Would the fact that PHP 5.5 doesn't ship as originally planed, if the
 mentioned integration happens, affect your view about PHP?
 - yes
 - no

 What position do you have in your company?
 - developer
 - sysadmin
 - devops
 - manager
 - other: type here

 Are you in a position to influence the upgrade from your current PHP
 version to PHP 5.5?
 - yes
 - no


 Afaik every major framework has someone here, on the ML, then we have
 Zend and we have some other libraries and so on here as well. Imagine
 if all those people would link from their websites to the said poll. I
 think it would be a small effort from them but the responses could at
 least point out to what users actually want and help you in sorting
 this out.

 If I offended anyone, which I'm almost sure I did, it was not my
 intention, please forgive me.

 Thank you all for your hard work on PHP.


And I've forgot the most important question:

Would you skip PHP 5.4 migration if the opcode caching were to be
included by default in PHP 5.5?
- yes
- no


Best regards

Florin Patan
https://github.com/dlsniper

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

2013-02-28 Thread Levi Morrison

 A huge, out of the box, speed bump for production machines.

For some applications PHP 5.4 was a huge speed bump out of the box . . .

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

On Thu, Feb 28, 2013 at 11:37 PM, Levi Morrison morrison.l...@gmail.com wrote:
 A huge, out of the box, speed bump for production machines.

 For some applications PHP 5.4 was a huge speed bump out of the box . . .

Would you run PHP against 10k+ req/s in production without opcode caching?
On how many machines without / with?


Florin Patan
https://github.com/dlsniper

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

Florin

Would you run PHP against 10k+ req/s in production without opcode caching?
 On how many machines without / with?


I'm not sure about your stack, but every stack I've seen at that high of a
load is built very custom for the problem at hand. And it isn't typically
upgraded across minor versions (in fact, it's typically only upgraded for
security). At least that's my experience everywhere I've seen that big of a
farm... And when it is upgraded, it's usually a very coordinated effort
that takes a LOT of planning and has a lot of moving parts...

And to be fair, how many installs are there that get 10k req/s? A few
hundred? That's not the kind of system we should be targeting when
discussing a language feature/change. Sure it's sexy, but it represents
less than 1% of the install base of PHP (much less, prob on the order of
0.01%). So while I wouldn't write them off (far from it), justifying a
change because it matters to that scale is like justifying ejection seats
in cars because hitting a wall at 200mph on a race track can kill you...

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

2013-02-28 Thread Levi Morrison

 Would you run PHP against 10k+ req/s in production without opcode caching?
 On how many machines without / with?

This is getting a bit off-topic now, but all my work is geared towards
tools for users and system administrators in the LAN. We don't need an
op-code cache. We never get more than six unique users per day with
fairly low traffic from each. Does that mean we aren't important? I
sure hope not. . .

For us the new features are more helpful (we have plans for generators
already) because it makes certain iterators easier to build and
maintain.

 I'm not sure about your stack, but every stack I've seen at that high of a
 load is built very custom for the problem at hand. And it isn't typically
 upgraded across minor versions (in fact, it's typically only upgraded for
 security). At least that's my experience everywhere I've seen that big of a
 farm... And when it is upgraded, it's usually a very coordinated effort that
 takes a LOT of planning and has a lot of moving parts...

 And to be fair, how many installs are there that get 10k req/s? A few
 hundred? That's not the kind of system we should be targeting when
 discussing a language feature/change. Sure it's sexy, but it represents less
 than 1% of the install base of PHP (much less, prob on the order of 0.01%).
 So while I wouldn't write them off (far from it), justifying a change
 because it matters to that scale is like justifying ejection seats in cars
 because hitting a wall at 200mph on a race track can kill you...

Completely agreed. How many millions of tiny sites use PHP compared to
the few that serve up that kind of traffic?

I'm not saying performance isn't a concern; I am saying that your
concern is not typical of the average PHP developer.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

2013-02-28 Thread Martin Nicholls

On 28/02/2013 13:54, Ilia Alshanetsky wrote:
 The major reason being is the lack of a stable, production ready op-code 
 cache.
Am I crazy or APC not stable != a lack of a stable opcode cache. Whole
discussion thread has been assuming people don't use anything and or
there's nothing better than both ZO *and* APC - both facts being
patently untrue. I hate to get adversarial about this stuff, but PHP
seems to be suffering with a serious case of Not Invented Here syndrome
at the moment.

Real world ZO isn't going to make people switch to PHP 5.5 and nothing
but distro movement on this issue (around their release process) and
good time are going to change that. It's always applied with PHP (and
many other languages and projects) and it always will. Linux kernel is
at 3.8.1 but Debian testing is shipping 3.2, because that's what the
release process demands. Most sane people are going to use the PHP
version their distro ships and most distros are going to ship what is
tested, and not for nothing but bundling ZO if anything is going to gum
up the works on that front because simply it's more code and features
that will need testing and more config options to find sane defaults for.

TL;DR - ZO isn't going to shift people.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

On Thu, Feb 28, 2013 at 11:47 PM, Anthony Ferrara ircmax...@gmail.com wrote:
 Florin

 Would you run PHP against 10k+ req/s in production without opcode caching?
 On how many machines without / with?


 I'm not sure about your stack, but every stack I've seen at that high of a
 load is built very custom for the problem at hand. And it isn't typically
 upgraded across minor versions (in fact, it's typically only upgraded for
 security). At least that's my experience everywhere I've seen that big of a
 farm... And when it is upgraded, it's usually a very coordinated effort that
 takes a LOT of planning and has a lot of moving parts...

 And to be fair, how many installs are there that get 10k req/s? A few
 hundred? That's not the kind of system we should be targeting when
 discussing a language feature/change. Sure it's sexy, but it represents less
 than 1% of the install base of PHP (much less, prob on the order of 0.01%).
 So while I wouldn't write them off (far from it), justifying a change
 because it matters to that scale is like justifying ejection seats in cars
 because hitting a wall at 200mph on a race track can kill you...



Anthony and Levi,


True but could we please get back to the whole mail and actually see
what the users want?

I would vote in the RFC if would be allowed to do so and I think I've
explained my perspective really well and the fact that I'm just one of
the hundred of thousands of PHP users.

I'm part of a very small group of people who have these problems, I
agree, but what I'm proposing should help out instead of just assuming
things.

The point is that this is yet another: we should this but that but
then and what if ... that could be solved by just asking the users and
taking that into account.

I could bet that people could care less about a stable release cycle
when things like this are at stake for certain versions.

Also, as a mention, I think that the current release every year target
is highly unrealistic unless you want to fragment the market the same
way that Google does it with Android. And look at the problems they
have with the adoption. If they can't serve as an example, I don't
know how can. Especially with PHP 5.4 experience. Are you willing to
bet that PHP 5.5 will do any better?



Best regards

Florin Patan
https://github.com/dlsniper

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

Stas,

Just to put things in perspective, if opcode caches with extended info
make it into the opcode cache - it's a bad thing.  So it's actually
expected that debuggers and opcode caches would have to be aware of
one another, but at a pretty minimal level.  The load order solves it
most probably because then it means Xdebug kicks in first, and
wouldn't pass op arrays to O+.  That's guesswork though, we'd have to
ensure that and ideally also have a mechanism to enforce it.

Sent from my tablet

On 28 בפבר 2013, at 22:49, Stas Malyshev smalys...@sugarcrm.com wrote:

 Hi!

 It works fine. You just have to load ZO before xdebug. If you load it
 the other way around bad things happen. This wrong load order currently

 Could you describe the bad things? Maybe we could have some checks in
 either of them to prevent it... Of course, we could probably make ZO
 just check if xdebug is loaded and react accordingly, but maybe we could
 resolve it in a more elegant way...

 --
 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] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

2013-02-28 Thread Jan Ehrhardt

Raymond Irving in php.internals (Thu, 28 Feb 2013 13:56:11 -0500):
I'm very sure users will not complain if 5.5 is delayed for a few months.
Most websites will not be installing 5.5 immediately after it has been
released.

On the contrary: many users will welcome it because it delays the EOL of
PHP 5.3 as well. The outcome of a previous vote was that PHP 5.3 would
become unsupported within, say, 14 months from now. An unbelievable
short time frame given the fact that many sites did not even migrate to
PHP 5.3.

JAn

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

Hi!

 Just to put things in perspective, if opcode caches with extended info
 make it into the opcode cache - it's a bad thing.  So it's actually

Yeah, we should definitely check for extended info and shortcut
compile_file immediately if that is there. Should be an easy patch, I'll
try to do pull tonight. If that's the problem behind Rasmus' crash, it's
easy to fix.

 expected that debuggers and opcode caches would have to be aware of
 one another, but at a pretty minimal level.  The load order solves it
 most probably because then it means Xdebug kicks in first, and
 wouldn't pass op arrays to O+.  That's guesswork though, we'd have to
 ensure that and ideally also have a mechanism to enforce it.

Yeah, that is what I was worried about if there's no other problems
deeper than the extended info one and how to handle it in an elegant
fashion without hardcoding checks for specific names.


-- 
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] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

2013-02-28 Thread David Muir


On 01/03/2013, at 9:22 AM, Jan Ehrhardt php...@ehrhardt.nl wrote:

 Raymond Irving in php.internals (Thu, 28 Feb 2013 13:56:11 -0500):
 I'm very sure users will not complain if 5.5 is delayed for a few months.
 Most websites will not be installing 5.5 immediately after it has been
 released.
 
 On the contrary: many users will welcome it because it delays the EOL of
 PHP 5.3 as well. The outcome of a previous vote was that PHP 5.3 would
 become unsupported within, say, 14 months from now. An unbelievable
 short time frame given the fact that many sites did not even migrate to
 PHP 5.3.
 
 JAn
 
 -- 
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 


There's all this talk about the lack of 5.4 adoption being related to the lack 
of an opcode cache. I think that's ridiculous. Most shared hosts that I know 
about do not even offer opcode caching, so that can't be the reason why they 
haven't upgraded.

I know of one host that said it was because Zend Guard no longer supported BSD 
after 5.2 (don't know if it has since been added back in because that host has 
since upgraded to 5.3). Others work with LTS distro releases like Ubuntu and 
Red Hat, neither of which are on 5.4 either. The next Ubuntu LTS release won't 
be out until April 2014, so don't expect a surge in 5.4 adoption (or whatever 
version 14.04 comes with) for at least another year.

For me personally, I'm running sites on 5.2 and 5.3. I am unable to upgrade to 
5.4 and beyond because of the removal of register_globals and magic_quotes_gpc. 
I am not complaining that they were removed. Those two settings have been a 
huge pain in the backside for years, and I'm glad they're gone. But the legacy 
software I have to maintain was written assuming they were available and on. It 
will take a *very* long time to fix and update all that code to run on 5.4.

Cheers,
David
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

On Feb 28, 2013 8:16 PM, Ilia Alshanetsky i...@prohost.org wrote:



 If ZO+ was a brand new code, I'd agree with you 100%. However, it is
 an existing solution that has been used in a wild in quite some time
 an limited empirical evidence shows that it works somewhat better than
 APC in most cases from stability perspective.

It is not the version provided before. Things have been removed, changed,
etc.

We both know that it is not an easy thing to do with an opcode cache.

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution