All,
Following the discussion at the end of last week, I prepared a draft RFC
for the inclusion of Optimizer+ in PHP.
In parallel we’re in the process of prepping the source code for
independent public consumption, which I hope we can be done with by the end
of next week, hopefully sooner.
https://wiki.php.net/rfc/optimizerplus
Comments welcome!
Zeev
hi Zeev!
All,
Following the discussion at the end of last week, I prepared a draft RFC
for the inclusion of Optimizer+ in PHP.In parallel we’re in the process of prepping the source code for
independent public consumption, which I hope we can be done with by the end
of next week, hopefully sooner.
Thanks!
https://wiki.php.net/rfc/optimizerplus
Comments welcome!
One important part missing is the actual compatibility/support of
thread safe PHP. I know that Zend mostly care about NTS since quite
some time and that worries me a lot to bundle something that is not
working well in thread safe mode. I would consider that as a stopping
point. I mean, not to stop its inclusion, but to release 5.5.0 with it
without optimizer working as good as APC in ts mode.
Cheers,
Pierre
@pierrejoye
One important part missing is the actual compatibility/support of thread
safe
PHP. I know that Zend mostly care about NTS since quite some time and
that
worries me a lot to bundle something that is not working well in thread
safe
mode. I would consider that as a stopping point. I mean, not to stop its
inclusion,
but to release 5.5.0 with it without optimizer working as good as APC in
ts
mode.
It's mentioned in the RFC - but I think we should be able to (re)add NTS
support pretty quickly.
Zeev
One important part missing is the actual compatibility/support of thread
safe
PHP. I know that Zend mostly care about NTS since quite some time and
that
worries me a lot to bundle something that is not working well in thread
safe
mode. I would consider that as a stopping point. I mean, not to stop its
inclusion,
but to release 5.5.0 with it without optimizer working as good as APC in
ts
mode.It's mentioned in the RFC - but I think we should be able to (re)add NTS
support pretty quickly.
Hey:
my problem gone. ignore my previous mail
thanks
Zeev
--
--
Laruence Xinchen Hui
http://www.laruence.com/
Zeev Suraski wrote:
Following the discussion at the end of last week, I prepared a draft RFC
for the inclusion of Optimizer+ in PHP.
Hey Zeev,
I see in the Benchmarks you tested with WordPress 2.1.1, however this
release is roughly 5 years old. Is it possible to get an updated test
with 3.5.1 (the latest release)?
(My guess is that it will show WP being slower and with a more dramatic
improvement.)
Thanks,
--
Ryan McCue
<http://ryanmccue.info/
-----Original Message-----
From: Ryan McCue [mailto:lists@rotorised.com]
Sent: Tuesday, January 29, 2013 10:13 AM
To: Zeev Suraski
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP
distributionZeev Suraski wrote:
Following the discussion at the end of last week, I prepared a draft
RFC for the inclusion of Optimizer+ in PHP.Hey Zeev,
I see in the Benchmarks you tested with WordPress 2.1.1, however this
release
is roughly 5 years old. Is it possible to get an updated test with 3.5.1
(the latest
release)?
You'd notice the entire test suite is more than a bit old :) It's been our
standard test suite for years so that we can keep comparing apples to
apples. We can definitely run tests on newer versions - and once we open it
up I think it'd be great if people contribute some of their own benchmarks!
(My guess is that it will show WP being slower and with a more dramatic
improvement.)
By the way, I just realized the % gain wasn't all that self-explanatory -
it's vs. APC, not vs. plain PHP. I improved the doc to reflect both gains
vs. plain PHP and vs. APC.
Thanks for the feedback!
Zeev
[snip]
(My guess is that it will show WP being slower and with a more dramatic
improvement.)
By the way, I just realized the % gain wasn't all that self-explanatory -
it's vs. APC, not vs. plain PHP. I improved the doc to reflect both gains
vs. plain PHP and vs. APC.
It's better now ;-).
Thank you for the contribution. It's a great news! Can APC and
Optimizer+ work in duo or share some features?
--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/
PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/
Member of HTML and WebApps Working Group of W3C
http://w3.org/
On Tue, Jan 29, 2013 at 4:33 PM, Ivan Enderlin @ Hoa
ivan.enderlin@hoa-project.net wrote:
[snip]
(My guess is that it will show WP being slower and with a more dramatic
improvement.)By the way, I just realized the % gain wasn't all that self-explanatory -
it's vs. APC, not vs. plain PHP. I improved the doc to reflect both gains
vs. plain PHP and vs. APC.It's better now ;-).
Thank you for the contribution. It's a great news! Can APC and Optimizer+
work in duo or share some features?
If O+ became opensource, I think it can be done by lots contributors.. :)
thanks
--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/Member of HTML and WebApps Working Group of W3C
http://w3.org/--
--
Laruence Xinchen Hui
http://www.laruence.com/
On Tue, Jan 29, 2013 at 4:33 PM, Ivan Enderlin @ Hoa
ivan.enderlin@hoa-project.net wrote:[snip]
(My guess is that it will show WP being slower and with a more dramatic
improvement.)
By the way, I just realized the % gain wasn't all that self-explanatory -
it's vs. APC, not vs. plain PHP. I improved the doc to reflect both gains
vs. plain PHP and vs. APC.
It's better now ;-).Thank you for the contribution. It's a great news! Can APC and Optimizer+
work in duo or share some features?
If O+ became opensource, I think it can be done by lots contributors.. :)thanks
--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/Member of HTML and WebApps Working Group of W3C
http://w3.org/--
Good news, if Optimizer+ will be integrated to PHP, that's amazing
improvement.
I vote:
Integrate Optimizer+ intoPHP5.5.0, allow up to 2 months delay
why we could waiting ? because PHP 5.4 is stable for production environment.
we could wait for more bit long time.
the big improvement is better than fast release.
we do not need release for release. no sense.
why not take us some surprise.
--
Appreciate your time.
Netroby
From the perspective of the end-user this would be really great!
If it could really be done in 2 months -> wait for it.
best regards.
From the perspective of the end-user this would be really great!
If it could really be done in 2 months -> wait for it.
Why should we break the PHP release process by 2 months+ to include O+ ?
There are alternatives (APC to name one) and O+ might also be used on
top of the core (I don't know it to be able to tell).
I think waiting 10 months (12-2) is preferrable and O+ would go in the
next PHP release (if accepted).
There is really no point in delaying a relase for a feature (vs a bug
fix) - even more when substitutes exist.
My 2 cents,
Victor
From the perspective of the end-user this would be really great!
If it could really be done in 2 months -> wait for it.best regards.
Considering the importance of opcode caches to any serious project these
days, I'd say a 2 month delay to get an integrated opcode cache working
on release day is absolutely worth it. I cannot speak to the relative
merits of APC vs. O+, or how reasonable that timeframe is, but if it is
an accurate estimate then from a userland perspective it would be a good
investment. (The "optimize for APC" vs. "optimize for shared host with
no APC" debate comes up in Drupal on a regular basis; being able to
count on one would allow us to optimize our own code far better.)
I entirely appreciate Anthony's concern about rule bending, but I think
this is a "feature request" at a level that such bending can be considered.
--Larry Garfield
By the way, I just realized the % gain wasn't all that self-explanatory -
it's vs. APC, not vs. plain PHP. I improved the doc to reflect both gains
vs. plain PHP and vs. APC.Thanks for the feedback!
Zeev
Zeev,
It would be useful to link to the current Optimizer+ doc from the RFC.
I believe the link is
http://static.zend.com/topics/Zend-Optimizer-User-Guide-v330-new.pdf
Can you comment (in the RFC) on differences that the open source code
may have from this documentation e.g. on what Zend Guard integration
will be included, or what obsolete features you might clean out?
I think an RFC should clearly state what the feature does and doesn't
work with. I.e. for this RFC list whether CLI, FastCGI, ZTS etc work.
Can you list potential platform or extension (XDebug) portability
issues?
The RFC still mentions Pierre helping with ZTS, which I believe is a
left-over comment??
Since the releae time-frame is an issue that may affect voting, the
RFC should also contain more details on what needs integrating.
Chris
--
christopher.jones@oracle.com http://twitter.com/ghrd
Newly updated, free PHP & Oracle book:
http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html
It would be useful to link to the current Optimizer+ doc from the RFC.
I believe the link is
http://static.zend.com/topics/Zend-Optimizer-User-Guide-v330-new.pdf
Different beast. Something like this is more apt:
http://files.zend.com/help/previous-version/Zend-Server-5-Community-Edition/zendoptimizerplus.html
which shows the dreaded zend_optimizerplus.inherited_hack which mimics
APC's autofilter hack. I'd love to get rid of this particular bit of
confusion/code complexity on the integration.
Can you comment (in the RFC) on differences that the open source code
may have from this documentation e.g. on what Zend Guard integration
will be included, or what obsolete features you might clean out?
Again, you are talking about a different product. Ignore any Zend Guard
stuff.
Can you list potential platform or extension (XDebug) portability
issues?
XDebug together with an opcode cache is always a shaky thing and not
something we should be too concerned about. You would never want to run
both in production. It would be good if they didn't clobber each other
for dev environment purposes, but I am sure we can figure that out.
-Rasmus
Hi!
which shows the dreaded zend_optimizerplus.inherited_hack which mimics
APC's autofilter hack. I'd love to get rid of this particular bit of
confusion/code complexity on the integration.
Ohh, this one. IIRC that has to do with conditional definition of
classes and the fact that script may be compiled in one environment but
loaded in another, which may create difference in class tables,
especially combined with early binding for inherited classes. Getting
rid of it is not that easy until people stop writing code like:
if($foo) return;
class Foo extends Bar {}
which would work differently depending on if Bar is defined or not.
XDebug together with an opcode cache is always a shaky thing and not
something we should be too concerned about. You would never want to run
both in production. It would be good if they didn't clobber each other
for dev environment purposes, but I am sure we can figure that out.
Yeah, it is a good idea for debugger to turn off any caching when
activated. I think given proper .ini switches it can be easily arranged.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
which shows the dreaded zend_optimizerplus.inherited_hack which mimics
APC's autofilter hack. I'd love to get rid of this particular bit of
confusion/code complexity on the integration.Ohh, this one. IIRC that has to do with conditional definition of
classes and the fact that script may be compiled in one environment but
loaded in another, which may create difference in class tables,
especially combined with early binding for inherited classes. Getting
rid of it is not that easy until people stop writing code like:
if($foo) return;
class Foo extends Bar {}
which would work differently depending on if Bar is defined or not.
Yes, I am quite familiar with it since we had to handle this in APC too.
But I don't think getting rid of it is that hard. It obviously can't be
done in the opcode cache because by the time the compiler hands us the
op_array we have already lost the FETCH_CLASS opcode which we may or may
not need. We need to look at whether that MAKE_NOP() call in the
compiler is actually a worthwhile optimization in a future where most
people will be running an opcode cache by default.
This is one of the prime examples of making the compiler more opcode
cache friendly. Yes, it may be at the slight expense of non-opcode cache
performance, but with a bundled opcode cache implementation that should
be less of a worry.
-Rasmus
Hi!
which shows the dreaded zend_optimizerplus.inherited_hack which mimics
APC's autofilter hack. I'd love to get rid of this particular bit of
confusion/code complexity on the integration.
Ohh, this one. IIRC that has to do with conditional definition of
classes and the fact that script may be compiled in one environment but
loaded in another, which may create difference in class tables,
especially combined with early binding for inherited classes. Getting
rid of it is not that easy until people stop writing code like:
if($foo) return;
class Foo extends Bar {}
which would work differently depending on if Bar is defined or not.
Yes, I am quite familiar with it since we had to handle this in APC too.
But I don't think getting rid of it is that hard. It obviously can't be
done in the opcode cache because by the time the compiler hands us the
op_array we have already lost the FETCH_CLASS opcode which we may or may
not need. We need to look at whether that MAKE_NOP() call in the
compiler is actually a worthwhile optimization in a future where most
people will be running an opcode cache by default.This is one of the prime examples of making the compiler more opcode
cache friendly. Yes, it may be at the slight expense of non-opcode cache
performance, but with a bundled opcode cache implementation that should
be less of a worry.
+1. This one makes no sense to me as it simply hoists the
zend_do_inheritance() from runtime binding to compile-time, and this
binding has to be backed out by any opcode cache to work properly. It
might save a few microseconds per class declaration in non-cached
performance, but add factors more to cached performance. Why do this?
Hi!
which shows the dreaded zend_optimizerplus.inherited_hack which mimics
APC's autofilter hack. I'd love to get rid of this particular bit of
confusion/code complexity on the integration.
Ohh, this one. IIRC that has to do with conditional definition of
classes and the fact that script may be compiled in one environment but
loaded in another, which may create difference in class tables,
especially combined with early binding for inherited classes. Getting
rid of it is not that easy until people stop writing code like:
if($foo) return;
class Foo extends Bar {}
which would work differently depending on if Bar is defined or not.
Yes, I am quite familiar with it since we had to handle this in APC too.
But I don't think getting rid of it is that hard. It obviously can't be
done in the opcode cache because by the time the compiler hands us the
op_array we have already lost the FETCH_CLASS opcode which we may or may
not need. We need to look at whether that MAKE_NOP() call in the
compiler is actually a worthwhile optimization in a future where most
people will be running an opcode cache by default.This is one of the prime examples of making the compiler more opcode
cache friendly. Yes, it may be at the slight expense of non-opcode cache
performance, but with a bundled opcode cache implementation that should
be less of a worry.
+1. This one makes no sense to me as it simply hoists the
zend_do_inheritance() from runtime binding to compile-time, and this
binding has to be backed out by any opcode cache to work properly. It
might save a few microseconds per class declaration in non-cached
performance, but add factors more to cached performance. Why do this?
I agree. And the code doesn't have to be as silly as the example Stas
gave. Something as simple as this will hit it:
indexA includes child1 and child2 which both extend parent1
indexB includes only child2
Assuming these are all in different files, if you hit indexA first, by
the time the compiler gets to child2 parent1 already exists because
child1 inheriting from it brought it in so it will be compiled without
the FETCH_CLASS opcode.
But then you hit the indexB entry point and now the compiled child2 is
used in a context that doesn't already provide parent1 so the cached
opcodes can't be used here.
Of course, if on an empty cache the indexB entry point is hit before the
indexA entry point, then everything is fine. child2 will be compiled
with the "FETCH_CLASS parent1" intact and this version can be used in
both contexts.
This is the kind of thing I really don't want to have to explain to
people with an integrated cache solution. It is a level of detail the
user should never hit.
-Rasmus
It would be useful to link to the current Optimizer+ doc from the RFC.
I believe the link is
http://static.zend.com/topics/Zend-Optimizer-User-Guide-v330-new.pdfDifferent beast. Something like this is more apt:
http://files.zend.com/help/previous-version/Zend-Server-5-Community-Edition/zendoptimizerplus.html
Ah, ack. The PECL extension and/or configure directive should use a
better name. This confusion reinforces my main point: the RFC needs
more detail about what PHP will end up having.
Can you list potential platform or extension (XDebug) portability
issues?XDebug together with an opcode cache is always a shaky thing and not
something we should be too concerned about. You would never want to run
both in production. It would be good if they didn't clobber each other
for dev environment purposes, but I am sure we can figure that out.
This is the kind of info the RFC (and then user doc) should have.
Chris
--
christopher.jones@oracle.com http://twitter.com/ghrd
Newly updated, free PHP & Oracle book:
http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html
XDebug together with an opcode cache is always a shaky thing and not
something we should be too concerned about. You would never want to
run both in production. It would be good if they didn't clobber each
other for dev environment purposes, but I am sure we can figure that
out.This is the kind of info the RFC (and then user doc) should have.
It should be easy to implement the same behavior we have with Zend Debugger
today also with Xdebug. The debugger essentially intercepts the compile()
callback before Optimizer+, and if it determines that the present request
should run through the debugger - it bypasses the Optimizer+ altogether and
calls directly into zend_compile_file(). I'll update the RFC that it should
be possible to integrate it nicely with any other modules.
Zeev
This is the kind of info the RFC (and then user doc) should have.
I updated the RFC with two extra sections - 'what's an opcode cache', and
'interaction with other plugins'.
https://wiki.php.net/rfc/optimizerplus
Zeev
Hi Zeev,
Specifically would it continue to work with the Zend Guard decoder (as it does now)?
Thanks,
John.
-----Original Message-----
From: Zeev Suraski [mailto:zeev@zend.com]
Sent: 30 January 2013 14:48
To: Christopher Jones
Cc: internals@lists.php.net
Subject: RE: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
This is the kind of info the RFC (and then user doc) should have.
I updated the RFC with two extra sections - 'what's an opcode cache', and 'interaction with other plugins'.
https://wiki.php.net/rfc/optimizerplus
Zeev
Hi Zeev,
Specifically would it continue to work with the Zend Guard decoder (as it does now)?
Our (Zend's) goal would be yes.
Zeev
This is the kind of info the RFC (and then user doc) should have.
I updated the RFC with two extra sections - 'what's an opcode cache',
This section extremely general and doesn't explain what the expected
feature set might look like. I'm not asking for absolute certainties,
just a technical description of what is and isn't the goal. Is it the
complete Optimizer+, are there potential cleanups, do you see it being
enabled (if not in PECL) or disabled by default, etc.
Did I miss seeing the link to the current optimizer+ documentation?
http://files.zend.com/help/previous-version/Zend-Server-5-Community-Edition/zendoptimizerplus.html
(thanks Rasmus)
Your email comment to John Carter about Zend Guard decoder is also not
(yet) in the RFC.
Chris
and 'interaction with other plugins'.
https://wiki.php.net/rfc/optimizerplus
Zeev
--
christopher.jones@oracle.com http://twitter.com/ghrd
Newly updated, free PHP & Oracle book:
http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html
Chris,
We're talking about a very specialized piece of software - an opcode cache
- nothing more, nothing less. It's not going to do anything beyond
implementing the concept of an opcode cache in php - no extra features.
Rasmus pointed out correctly that this component has nothing to do with the
Optimizer (sans +). It will also not have any special interaction with
Zend Guard, beyond perhaps the same mechanisms I mentioned might be useful
for debuggers (controlling the order of compile/exec callbacks, already in
the RFC). Supporting Zend Guard would be Zend's headache - not php.net's -
and wouldn't require any special treatment.
At the end of the day it's supposed to integrate cleanly into php without
any negative impact - not on functionality nor compatibility.
In terms of what integration would entail - my intent was that integration
means that it's on by default. I'll clarify that in the RFC, unless people
think we should put that up for discussion..?
Sent from my mobile
On 1 בפבר 2013, at 08:48, Christopher Jones christopher.jones@oracle.com
wrote:
This is the kind of info the RFC (and then user doc) should have.
I updated the RFC with two extra sections - 'what's an opcode cache',
This section extremely general and doesn't explain what the expected
feature set might look like. I'm not asking for absolute certainties,
just a technical description of what is and isn't the goal. Is it the
complete Optimizer+, are there potential cleanups, do you see it being
enabled (if not in PECL) or disabled by default, etc.
Did I miss seeing the link to the current optimizer+ documentation?
http://files.zend.com/help/previous-version/Zend-Server-5-Community-Edition/zendoptimizerplus.html
(thanks Rasmus)
Your email comment to John Carter about Zend Guard decoder is also not
(yet) in the RFC.
Chris
and 'interaction with other plugins'.
https://wiki.php.net/rfc/optimizerplus
Zeev
--
christopher.jones@oracle.com http://twitter.com/ghrd
Newly updated, free PHP & Oracle book:
http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html
In terms of what integration would entail - my intent was that integration
means that it's on by default. I'll clarify that in the RFC, unless people
think we should put that up for discussion..?
The hardest thing about that is figuring out the defaults. Setting the
shared memory segment size being the primary thing. But if a reset in ZO
is low-overhead, I suppose setting a conservatively low cache size isn't
going to cause too many problems. With APC because of its memory
manager, once the segment starts to fill up things start to slow down a
bit as it ends up spending time hunting for free blocks to use.
Also, if we are going to turn it on by default I'd really like to get
rid of zend_optimizerplus.inherited_hack and zend_optimizerplus.dups_fix
since they are both quite hard to explain to users and hit things a user
really shouldn't have to concern themselves about. With the integration
we should be able to convince the compiler to give us op_arrays we don't
need to have hacks for here.
-Rasmus
On Wed, Jan 30, 2013 at 1:17 AM, Christopher Jones
christopher.jones@oracle.com wrote:
The RFC still mentions Pierre helping with ZTS, which I believe is a
left-over comment??
No, it is on purpose and a pro for those worrying about ZTS.
Cheers,
Pierre
@pierrejoye
All,
Following the discussion at the end of last week, I prepared a draft RFC
for the inclusion of Optimizer+ in PHP.In parallel we’re in the process of prepping the source code for
independent public consumption, which I hope we can be done with by the end
of next week, hopefully sooner.
Thanks!
It's great. however, it's a little not perfect that no ZTS supports. :)
https://wiki.php.net/rfc/optimizerplus
Comments welcome!
Zeev
--
Laruence Xinchen Hui
http://www.laruence.com/
Thank you for this great initiative!
As a user, I could definitely wait for 2-3 more months and get
a good implementation/integration of this rather that have to
wait for at least one year.
I think it would also be nice if this could come as default
enabled since this way people would be able to notice the
advantages of having it enabled. Or you can run a survey on
php.net to see what are the options.
I do have one thing to ask you about this.
If we do wait 2 months, will the underlaying changes be able
to integrate easy with APC/XCache/eAccelerator/others?
Opcodes are a must for large traffic websites like those I'm
working on right now, so we clearly want to have such a thing
installed on our servers as soon as we install a new PHP
version. But if including O+ will mean that APC gets delayed
6+ months (see PHP 5.4) it would be a show stopper for us
upgrading to PHP 5.5.
Our upgrade process is like this: be at least one year on market
to iron out major/obvious bugs. If APC gets on the market 6
months after PHP 5.5 only because of this then we'll be near
PHP 5.6 by then. And we can't just change from APC to others
as we'll need to test them as well as see which other use data
caching like APC has.
It would make sense to actually see how the whole ZE can
be improved so that it makes life of opcode cachers easier
and then ship O+ bundled with a PHP version that has better
support for them out of the box if I were to choose.
Best regards,
Florin
Florin Patan
https://github.com/dlsniper
http://www.zend.com/en/yellow-pages#show-ClientCandidateID=ZEND013894
All,
Following the discussion at the end of last week, I prepared a draft RFC
for the inclusion of Optimizer+ in PHP.In parallel we’re in the process of prepping the source code for
independent public consumption, which I hope we can be done with by the end
of next week, hopefully sooner.https://wiki.php.net/rfc/optimizerplus
Comments welcome!
Zeev
On Tue, Jan 29, 2013 at 11:26 AM, Florin Razvan Patan <florinpatan@gmail.com
wrote:
Thank you for this great initiative!
As a user, I could definitely wait for 2-3 more months and get
a good implementation/integration of this rather that have to
wait for at least one year.I think it would also be nice if this could come as default
enabled since this way people would be able to notice the
advantages of having it enabled. Or you can run a survey on
php.net to see what are the options.I do have one thing to ask you about this.
If we do wait 2 months, will the underlaying changes be able
to integrate easy with APC/XCache/eAccelerator/others?Opcodes are a must for large traffic websites like those I'm
working on right now, so we clearly want to have such a thing
installed on our servers as soon as we install a new PHP
version. But if including O+ will mean that APC gets delayed
6+ months (see PHP 5.4) it would be a show stopper for us
upgrading to PHP 5.5.Our upgrade process is like this: be at least one year on market
to iron out major/obvious bugs. If APC gets on the market 6
months after PHP 5.5 only because of this then we'll be near
PHP 5.6 by then. And we can't just change from APC to others
as we'll need to test them as well as see which other use data
caching like APC has.It would make sense to actually see how the whole ZE can
be improved so that it makes life of opcode cachers easier
and then ship O+ bundled with a PHP version that has better
support for them out of the box if I were to choose.
please don't top on this list, we prefer bottom or inline posting around
here, see http://www.php.net/reST/README.MAILINGLIST_RULES
back to the topic: personally I think that even two months seems like a
tight schedule as we are talking about incorporating an opcode cache, which
I'm pretty sure that it is similar in complexity to apc, and are only like
a handful of people on the planet has any experience working with, and
needs some polishing and has at least one known shortcoming (thread safety).
my opinion is that we should wait for the code to be released before
thinking about the release dates.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
This is really exciting!
As a user, I say allow a delay to get this into 5.5. I was kind of disappointed that some cache wasn't bundled with 5.4. It's been too long that this very important piece has been separate from the core.
Cheers
Zeev,
First off, very nice job on the RFC. I definitely like what's happening
here.
As far as delaying 5.5, I have mixed feelings. I think we should definitely
consider the delay, but only in a time-boxed format. So if we say "1
month", then if it's not ready to be committed in that month, it doesn't
get in and we release 5.5 anyway. I don't think we should do an indefinite
(not hard-defined) delay, as we could wind up in a situation similar to 6,
where for some reason we wind up delayed for 6 months or worse. I'm not
saying I think it'll happen, but we should be careful to limit it.
In addition, I would suggest putting in a feature freeze for everything
except this feature as well. Not because we shouldn't have new features,
but to prevent another "everyone wants this, so let's delay some more"
feature 1 week before the timebox expires.
Additionally, I don't like the precedent that this sets for future
releases. That it's ok to break the timebox for some feature. In this case
I think we can justify it, but future cases may use this to justify waiting
when it's not completely justified in itself. I'm not sure how we can
rectify this concern, but I figured it was worth mentioning.
Anthony
This is really exciting!
As a user, I say allow a delay to get this into 5.5. I was kind of
disappointed that some cache wasn't bundled with 5.4. It's been too long
that this very important piece has been separate from the core.Cheers
Zeev,
First off, very nice job on the RFC. I definitely like what's happening
here.As far as delaying 5.5, I have mixed feelings. I think we should definitely
consider the delay, but only in a time-boxed format. So if we say "1
month", then if it's not ready to be committed in that month, it doesn't
get in and we release 5.5 anyway.
Do you really think a month would be enough (we're talking implementation
and really thorough testing)?
We're fast approaching beta and the feature freeze, and this is by no means
a small feature (correct me if I am mistaken).
I think this would very much benefit from the time between releases to get
it really thoroughly integrated and tested. Far more eyes will see it, and
contribute to it in the time between 5.5 and 5.6 than if it is rushed for
5.5. Stability is king when it comes to adoption, and we really don't need
an edge case coming up at the last minute that gives people another reason
not to upgrade.
In addition, I would suggest putting in a feature freeze for everything
except this feature as well. Not because we shouldn't have new features,
but to prevent another "everyone wants this, so let's delay some more"
feature 1 week before the timebox expires.
That would allow more focused testing and development on this specific
feature, but...
Additionally, I don't like the precedent that this sets for future
releases.
.. this.
There has already been a couple of discussions this week around "rule
bending" (voting / bc breaks). I think the release schedule is an important
one to stick to.
Is it possible to introduce O+ via PECL in the interim?
Additionally, I don't like the precedent that this sets for future
releases. That it's ok to break the timebox for some feature. In this case
I think we can justify it, but future cases may use this to justify waiting
when it's not completely justified in itself. I'm not sure how we can
rectify this concern, but I figured it was worth mentioning.
I would agree with this sentiment, time boxing from my own personal
experience just completely breaks down if you let anything get in the
way of it, if you let that box slip for any reason, other reasons become
easily justifyable. If 5.5 is due for release, we should not delay it
for 2 months to get an opcode cache into core.
Additionally:
-
I believe Optimizer+ is the opcode cache that's been discussed but
it's not thread safe? -
Isn't APC the standard? Is it in such bad shape it is not even being
considered any longer? -
There has never been a bundled opcode cache that I'm aware of, one
more release without one is not going to surprise many people -
Waiting for a 5.6 release will give everyone an entire year to get
this into core and well tested which based on all the hoopla about how
critical APC/opcode caches are to the core it makes sense that
integration is going to be a long and painful process.
--
-Clint
-----Original Message-----
From: Clint Priest [mailto:cpriest@zerocue.com]
Sent: Tuesday, January 29, 2013 3:30 PM
To: Anthony Ferrara
Cc: Tyler Sommer; Zeev Suraski; internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP
distributionAdditionally, I don't like the precedent that this sets for future
releases. That it's ok to break the timebox for some feature. In this
case I think we can justify it, but future cases may use this to
justify waiting when it's not completely justified in itself. I'm not
sure how we can rectify this concern, but I figured it was worth
mentioning.
I would agree with this sentiment, time boxing from my own personal
experience just completely breaks down if you let anything get in the
way of it, if
you let that box slip for any reason, other reasons become easily
justifyable. If
5.5 is due for release, we should not delay it for 2 months to get an
opcode
cache into core.Additionally:
- I believe Optimizer+ is the opcode cache that's been discussed but
it's not
thread safe?
It's presently not thread safe. Just to be sure we're all on the same
page, this is only meaningful if you're running PHP on Windows and not
using FastCGI; It's completely meaningless in any other scenario (i.e.
for the vast majority of users); That said, adding thread safety support
for Optimizer+ is a fairly easy task. We've never done it because none of
our commercial products use thread-safe PHP. I'll update the RFC to
clarify the scope of this limitation.
- Isn't APC the standard? Is it in such bad shape it is not even being
considered
any longer?
Did you read the RFC? Yes, it is considered, and it's certainly an option
on the table, with advantages and disadvantages. There's a whole section
in the RFC about it.
There has never been a bundled opcode cache that I'm aware of, one
more
release without one is not going to surprise many peopleWaiting for a 5.6 release will give everyone an entire year to get
this into core
and well tested which based on all the hoopla about how critical
APC/opcode
caches are to the core it makes sense that integration is going to be a
long and
painful process.
I for one am not very fond of having a release every 12 months, and the
current pace of every 18 month seems rapid enough. So we'd be talking
about a year and a half, not a year. My opinion is that looking at our
adoption patterns, delaying by 2 months and providing an opcode cache
right off the bat would be much preferable to the vast majority of users.
People are barely using 5.4 today - it would hardly make a difference if
we release 5.5 two months earlier or two months later. But that too would
be up for discussion and voting.
Zeev
From: Clint Priest [mailto:cpriest@zerocue.com]:
Additionally, I don't like the precedent that this sets for future
releases. That it's ok to break the timebox for some feature. In
this case I think we can justify it, but future cases may use this
to justify waiting when it's not completely justified in itself.
I'm not sure how we can rectify this concern, but I figured it was
worth mentioning.I would agree with this sentiment, time boxing from my own personal
experience just completely breaks down if you let anything get in
the way of it, if you let that box slip for any reason, other
reasons become easily justifyable. If 5.5 is due for release, we
should not delay it for 2 months to get an opcode cache into core.Additionally:
- I believe Optimizer+ is the opcode cache that's been discussed
but it's not thread safe?It's presently not thread safe. Just to be sure we're all on the same
page, this is only meaningful if you're running PHP on Windows and not
using FastCGI; It's completely meaningless in any other scenario (i.e.
for the vast majority of users); That said, adding thread safety support
for Optimizer+ is a fairly easy task. We've never done it because none of
our commercial products use thread-safe PHP. I'll update the RFC to
clarify the scope of this limitation.
I wouldn't bother making it work with ZTS. If you want performance, you
shouldn't be using it, and the other case I heard was "pthreads" in
which case it plays no role,as all of the script is in memory anyway
for the duration of the process.
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine
Am 29.1.2013 um 15:58 schrieb Derick Rethans derick@php.net:
I wouldn't bother making it work with ZTS. If you want performance, you
shouldn't be using it, and the other case I heard was "pthreads" in
which case it plays no role,as all of the script is in memory anyway
for the duration of the process.cheers,
Derick--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine--
Hi,
you want to say someone who wants to use pthreads,
should have to maintain two different installations of php,
one with zts for the daemon and one without for the
apache?
Having to maintain only one installation makes life really
easier...
regards,
Bob
Am 29.1.2013 um 15:58 schrieb Derick Rethans derick@php.net:
I wouldn't bother making it work with ZTS. If you want performance,
you shouldn't be using it, and the other case I heard was "pthreads"
in which case it plays no role,as all of the script is in memory
anyway for the duration of the process.you want to say someone who wants to use pthreads, should have to
maintain two different installations of php, one with zts for the
daemon and one without for the apache? Having to maintain only one
installation makes life really easier...
Really? I have like 20 of them. Hardly a sweat. This includes 5.1->5.5,
zts and even 32bit builds. I suggest you educate yourself on installing
- and as a hint: http://derickrethans.nl/multiple-php-version-setup.html
cheers,
Derick
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine
- Isn't APC the standard? Is it in such bad shape it is not even being
considered any longer?
As it currently stands from a developer participation standpoint it is
not viable. I outlined the issues in a previous post.
You also have to take into account that most sites can't actually move
to the next release of PHP until APC is stable with it. So effectively
the PHP 5.4 release didn't happen until APC 3.1.13 in September 2012
which was a full 6 months after PHP 5.4.0. I don't foresee this getting
any better for PHP 5.5.
In order for PHP releases to actually mean something this is a problem
we have to fix. I honestly don't care which opcode cache implementation
we base a core version on, what I care about is developer buy-in. Dmitry
and Stas being familiar with the code already outnumbers the number of
active core devs working on APC today.
I understand some of the skepticism and hurt feelings around this from a
few old-timers, but let's move on and see if we can finally push out a
release with solid opcode caching right at the release date. From my
perspective anything up to a 6-month delay would beat the current situation.
-Rasmus
- Isn't APC the standard? Is it in such bad shape it is not even being
considered any longer?As it currently stands from a developer participation standpoint it is
not viable. I outlined the issues in a previous post.You also have to take into account that most sites can't actually move
to the next release of PHP until APC is stable with it. So effectively
the PHP 5.4 release didn't happen until APC 3.1.13 in September 2012
which was a full 6 months after PHP 5.4.0. I don't foresee this getting
any better for PHP 5.5.In order for PHP releases to actually mean something this is a problem
we have to fix. I honestly don't care which opcode cache implementation
we base a core version on, what I care about is developer buy-in. Dmitry
and Stas being familiar with the code already outnumbers the number of
active core devs working on APC today.I understand some of the skepticism and hurt feelings around this from a
few old-timers, but let's move on and see if we can finally push out a
release with solid opcode caching right at the release date. From my
perspective anything up to a 6-month delay would beat the current
situation.
I'm not sure I fully understand this. The RFC claims that Optimizer+ is
already now fully compatible with PHP 5.5. And that it was also
compatible when PHP 5.4 was released. So they lack of a working and free
opcode cache clearly wasn't the issue. My guess is rather that the lack of
APC support (as in specifically APC and not just some opcode cache) was an
issue. Either because people didn't know about alternatives (APC after all
is the go-to opcode cache), didn't want to try them or had software tightly
integrated with APC (and in particular its user cache).
Just to be clear: I fully agree that PHP needs a working opcode cache when
PHP 5.5 ships, otherwise adoption will be like 5.4. But I'm not sure what
exactly changes between Optimizer+ being in core (enable via configure) and
Optimizer+ being in PECL (enable via install).
The main point I always saw behind including APC in core is that it would
require core developers to maintain it and to update it when doing ZE
changes, on their own. This doesn't seem to be a motivation for Optimizer+.
Apart from that I see rather little difference between core/pecl. Opcode
caching is the kind of thing where the "if it's in pecl nobody will use it"
logic does not apply, as people using opcode caches run their own servers.
I do get that opcode caching
is commonly needed, so it would be nice to have it in core (easier
installation?), but I don't see why we should put off the release for one,
two, or more months, for that small convenience.
Thanks,
Nikita
I'm not sure I fully understand this. The RFC claims that Optimizer+ is
already now fully compatible with PHP 5.5. And that it was also
compatible when PHP 5.4 was released. So they lack of a working and free
opcode cache clearly wasn't the issue. My guess is rather that the lack
of APC support (as in specifically APC and not just some opcode cache)
was an issue. Either because people didn't know about alternatives (APC
after all is the go-to opcode cache), didn't want to try them or had
software tightly integrated with APC (and in particular its user cache).
Closed source isn't an option for many sites.
Hi Zeev,
Am 29.01.2013 um 15:21 schrieb Rasmus Lerdorf rasmus@lerdorf.com:
I'm not sure I fully understand this. The RFC claims that Optimizer+ is
already now fully compatible with PHP 5.5. And that it was also
compatible when PHP 5.4 was released. So they lack of a working and free
opcode cache clearly wasn't the issue. My guess is rather that the lack
of APC support (as in specifically APC and not just some opcode cache)
was an issue. Either because people didn't know about alternatives (APC
after all is the go-to opcode cache), didn't want to try them or had
software tightly integrated with APC (and in particular its user cache).
[...]
I personally find it quite cool, that Zend considers open sourcing its Optimizer+ product. I’m obviously just guessing, but I am halfway sure, that APC (and XCache etc.) have a lot to do with Zend being willing to do that move. In a sense that it helped making opcode caches a commodity. Maybe that’s a small solace for the countless hours that where spent on APC. To get more practical, I see the following steps going forward:
1.) Zend releases a first open sourced version of Optimizer+ on PECL (or somewhere else)
2.) We as a community can have a look at the code
3.) We vote on the RFC
3a.) Question a) Should Optimizer+ be included in core: yes/no
3b.) Question b) If yes, may the inclusion delay 5.5 by X month: yes/no
4.) The proposers make sure it works with ZTS as well (this obviously doesn’t exclude help from outside contributors)
@Zeev, out of interest, how much time does Zend plan to spend on maintaining Optimizer+ in the core for the foreseeable future?
cu,
Lars
-----Original Message-----
From: Lars Strojny [mailto:lars@strojny.net]
Sent: Tuesday, January 29, 2013 4:33 PM
To: Rasmus Lerdorf
Cc: Nikita Popov; internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP
distribution
To get more practical, I see the
following steps going forward:1.) Zend releases a first open sourced version of Optimizer+ on PECL
(or
somewhere else)
2.) We as a community can have a look at the code
3.) We vote on the RFC
3a.) Question a) Should Optimizer+ be included in core: yes/no
3b.) Question b) If yes, may the inclusion delay 5.5 by X month: yes/no
4.) The proposers make sure it works with ZTS as well (this obviously
doesn't
exclude help from outside contributors)
This is roughly the roadmap we have in mind. Given that some people are
eager not to delay 5.5.0 either at all or more than we absolutely have to,
I figured I'd parallelize the discussion and the work we're doing to prep
it for open sourcing. We're already well under way into that process, and
I'm hopeful we can publish it within a week or so.
BTW, Dmitry already baked ZTS support in earlier today. I said it
shouldn't take too long :)
@Zeev, out of interest, how much time does Zend plan to spend on
maintaining
Optimizer+ in the core for the foreseeable future?
We view it as an essential part of the PHP stack so we'll maintain it in
the same manner we help maintain the Zend Engine.
Zeev
I'm not sure I fully understand this. The RFC claims that Optimizer+ is
already now fully compatible with PHP 5.5. And that it was also
compatible when PHP 5.4 was released. So they lack of a working and free
opcode cache clearly wasn't the issue. My guess is rather that the lack
of APC support (as in specifically APC and not just some opcode cache)
was an issue. Either because people didn't know about alternatives (APC
after all is the go-to opcode cache), didn't want to try them or had
software tightly integrated with APC (and in particular its user cache).Closed source isn't an option for many sites.
So then this is a solved issue, right? Zend will open source Optimizer+
(very cool!). Everyone gets a working opcode cache (win), the release is
not delayed (win). For 5.6 it can be included into the distribution (a bit
more win).
Nikita :)
Hi Zeev
2013/1/29 Zeev Suraski zeev@zend.com:
In parallel we’re in the process of prepping the source code for
independent public consumption, which I hope we can be done with by the end
of next week, hopefully sooner.
I'm sorry, but I don't see why we out of a sudden should consider
adding a Zend product to the core, over that we got already, yes I'm
pointing in APC's direction, although it is in PECL.
I'm not trying to bring in this skepticism here because I'm, a
previous APC dev, but mostly because I do not think this is the right
move. Why? Because we tried to push APC from PECL into the Core since
early 5.x, although I've only been around since just before 5.3a1, I
remember how we were all focused on putting APC into the Core rather
than a non php.net project (like XCache, eAccelerator, ...), where
many of the core developers have invested much time in promoting APC,
and tried to fix some of the issues it have had. Moving APC into the
core was against some people's PoV because they thought it would be
enabled by default, which it wouldn't be at all.
I am very strongly against this move if its approved (not the actual
RFC), but how an outside product suddenly deserves a spot in the core
over our own code, by that I mean folks that does not work for Zend,
but have contributed the code to php.net, I think that is highly
controversial.
--
regards,
Kalle Sommer Nielsen
kalle@php.net
Hi Zeev
2013/1/29 Zeev Suraski zeev@zend.com:
In parallel we’re in the process of prepping the source code for
independent public consumption, which I hope we can be done with by the end
of next week, hopefully sooner.I'm sorry, but I don't see why we out of a sudden should consider
adding a Zend product to the core, over that we got already, yes I'm
pointing in APC's direction, although it is in PECL.
I'm not trying to bring in this skepticism here because I'm, a
previous APC dev, but mostly because I do not think this is the right
move. Why? Because we tried to push APC from PECL into the Core since
early 5.x,
It is not done yet. But given that the code is clean and easily
maintainable, it could be much more efficient for us to focus on one
extension and make it rock instead of trying to get each of them work
well. As Rasmus stated, between the opcode/engine and the way such
extensions work, we only have a handful of developers able to work on
them, and not full time.
Cheers,
Pierre
@pierrejoye
Hi Pierre
2013/1/29 Pierre Joye pierre.php@gmail.com:
It is not done yet. But given that the code is clean and easily
maintainable, it could be much more efficient for us to focus on one
extension and make it rock instead of trying to get each of them work
well. As Rasmus stated, between the opcode/engine and the way such
extensions work, we only have a handful of developers able to work on
them, and not full time.
I totally agree that having one extension and making it work
altogether is better, but the way I see it presented is that Zend
wants to lends us a hand if we pick their product, FOSS it and put it
into the core, so we got some more people working on it (I won't say
full time), but I'm sure that if its a Zend product there are gonna be
some more attention to it from their side.
--
regards,
Kalle Sommer Nielsen
kalle@php.net
-----Original Message-----
From: kalle.php@gmail.com [mailto:kalle.php@gmail.com] On Behalf Of
Kalle
Sommer Nielsen
Sent: Tuesday, January 29, 2013 3:28 PM
To: Zeev Suraski
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP
distributionHi Zeev
2013/1/29 Zeev Suraski zeev@zend.com:
In parallel we're in the process of prepping the source code for
independent public consumption, which I hope we can be done with by
the end of next week, hopefully sooner.I'm sorry, but I don't see why we out of a sudden should consider adding
a Zend
product to the core, over that we got already, yes I'm pointing in APC's
direction, although it is in PECL.
The RFC explains the pros and cons of doing that, I don't really have any
additional reasons to add beyond what I already put there. I believe the
pros outweigh the cons by a good considerable margin, but that's what the
vote would be about. Perhaps the one thing worth adding is that the
people who worked on Optimizer+ are all major php.net contributors,
including Dmitry, Stas, Andi and myself - it's not some alien artifact.
Zeev
2013/1/29 Zeev Suraski zeev@zend.com:
The RFC explains the pros and cons of doing that, I don't really have any
additional reasons to add beyond what I already put there. I believe the
pros outweigh the cons by a good considerable margin, but that's what the
vote would be about. Perhaps the one thing worth adding is that the
people who worked on Optimizer+ are all major php.net contributors,
including Dmitry, Stas, Andi and myself - it's not some alien artifact.
I don't doubt any of your abilities, what I do doubt is that how we
can consider an outside project directly into the core. APC would
without a doubt be up to pair if there was more people willingly to
dwell into it (yes dwell as many people see it as an alien artifact
because it touches and modifies some "unusual" things that the average
extension developer don't).
--
regards,
Kalle Sommer Nielsen
kalle@php.net
-----Original Message-----
From: kalle.php@gmail.com [mailto:kalle.php@gmail.com] On Behalf Of
Kalle
Sommer Nielsen
Sent: Tuesday, January 29, 2013 3:45 PM
To: Zeev Suraski
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP
distribution2013/1/29 Zeev Suraski zeev@zend.com:
The RFC explains the pros and cons of doing that, I don't really have
any additional reasons to add beyond what I already put there. I
believe the pros outweigh the cons by a good considerable margin, but
that's what the vote would be about. Perhaps the one thing worth
adding is that the people who worked on Optimizer+ are all major
php.net contributors, including Dmitry, Stas, Andi and myself - it's
not some
alien artifact.I don't doubt any of your abilities, what I do doubt is that how we can
consider
an outside project directly into the core. APC would without a doubt be
up to
pair if there was more people willingly to dwell into it (yes dwell as
many people
see it as an alien artifact because it touches and modifies some
"unusual" things
that the average extension developer don't).
I wasn't talking about our abilities, but about our 'outsideness'. Yes,
it is/was a closed source component, but it's by the same people that have
written a huge deal of PHP's scripting engine.
I'd would of course prefer that we evaluate the proposal based on the
substance and not on other factors, but that said, I fully respect your
position and wouldn't hold it against you if you vote 'no'...
Zeev
2013/1/29 Zeev Suraski zeev@zend.com:
I'd would of course prefer that we evaluate the proposal based on the
substance and not on other factors, but that said, I fully respect your
position and wouldn't hold it against you if you vote 'no'...
My vote will ofcourse also take the RFC into consideration, else it
would be a pointless vote, if it was an addition to PECL my vote would
be a direct yes however, but directly into the core, no. As Nikita
said in the previous post, we really need an opcode cacher in 5.5, but
I still have a hard time seeing the justification of this, although
its written by some of the longest time contributors in PHP's history.
--
regards,
Kalle Sommer Nielsen
kalle@php.net
Kalle Sommer Nielsen wrote:
2013/1/29 Zeev Suraskizeev@zend.com:
The RFC explains the pros and cons of doing that, I don't really have any
additional reasons to add beyond what I already put there. I believe the
pros outweigh the cons by a good considerable margin, but that's what the
vote would be about. Perhaps the one thing worth adding is that the
people who worked on Optimizer+ are all major php.net contributors,
including Dmitry, Stas, Andi and myself - it's not some alien artifact.
I don't doubt any of your abilities, what I do doubt is that how we
can consider an outside project directly into the core. APC would
without a doubt be up to pair if there was more people willingly to
dwell into it (yes dwell as many people see it as an alien artifact
because it touches and modifies some "unusual" things that the average
extension developer don't).
A fresh injection of 'blood' may do wonders? Since there are other options to
APC which may be alternative candidates, on one hand it makes perfect sense that
such a knowledgeable clean sheet is at least considered especially since the
code is almost feature complete? But providing it as another external (PECL)
option initially makes more sense? If only to allow comparison with APC,
eaccelerator and the rest?
I'll get my head chewed off again, but can we no consider doing that as PHP6
given that 6.0.x could be a development stage. I would perhaps then strongly
lobby for 'only' having E_STRICT mode so things like 'static $this' go by the by
anyway? This would not rule out a 5.5 with just the current suit of extras
although personally I'd prefer a longer maintained 5.4 with just the extras
that dovetail well included.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
2013/1/29 Lester Caine lester@lsces.co.uk:
I'll get my head chewed off again, but can we no consider doing that as PHP6
given that 6.0.x could be a development stage. I would perhaps then strongly
lobby for 'only' havingE_STRICTmode so things like 'static $this' go by
the by anyway? This would not rule out a 5.5 with just the current suit of
extras although personally I'd prefer a longer maintained 5.4 with just the
extras that dovetail well included.
What is 'static $this', and how does E_STRICT belong to this whole discussion?
--
regards,
Kalle Sommer Nielsen
kalle@php.net
Kalle Sommer Nielsen wrote:
2013/1/29 Lester Caine lester@lsces.co.uk:
I'll get my head chewed off again, but can we no consider doing that as PHP6
given that 6.0.x could be a development stage. I would perhaps then strongly
lobby for 'only' havingE_STRICTmode so things like 'static $this' go by
the by anyway? This would not rule out a 5.5 with just the current suit of
extras although personally I'd prefer a longer maintained 5.4 with just the
extras that dovetail well included.What is 'static $this', and how does
E_STRICTbelong to this whole discussion?
[VOTE] Deprecate and remove calls from incompatible context
This is another area where a major overhaul needs a major version number shift.
Just looking at this as an overview of where we ideally want to be quicker than
going through 5.5/5.6 releases would allow. Alright the optimizer could simply
remain an extra that anybody can use now, but planning a streamlined PHP6
release which 'ZTS', 'mysql' and the like could be formally sorted out?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Hi!
I don't doubt any of your abilities, what I do doubt is that how we
can consider an outside project directly into the core. APC would
How it's more "outside product" than any of the other extensions we
brought to the core?
without a doubt be up to pair if there was more people willingly to
dwell into it (yes dwell as many people see it as an alien artifact
If.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi
2013/1/30 Stas Malyshev smalyshev@sugarcrm.com:
How it's more "outside product" than any of the other extensions we
brought to the core?
Because it was not developed at php.net for example? How many
extensions thats in the core today was not developed somewhere at
php.net, or was either in PECL first? What I'm saying is that I think
it should go to PECL first before getting adapted into the core, no
matter who or where it was developed from if it was not developed
here, yes I realize I make it sound like an alien artifact as Zeev
said.
What if the guys at XCache asked for it to be added to the main
distribution, I'm pretty sure that most would say let it to go PECL or
compare it with APC and have a race there, but the fact that it is
(with all respect) guys who worked heavily on the Engine seems to
blind some people, which is what I'm against.
--
regards,
Kalle Sommer Nielsen
kalle@php.net
What if the guys at XCache asked for it to be added to the main
distribution, I'm pretty sure that most would say let it to go PECL or
Isn't the important thing whether it survives the RFC/voting process? If devs agree with
you that time served in PECL is essential, they can vote it down. If XCache would be
better, someone could submit an RFC...
Steve Clay
Hi!
Because it was not developed at php.net for example? How many
I'm not sure what is the meaning here. Nothing is developed "at
php.net", strictly speaking. php.net doesn't have its own development
team that works exclusively for php.net, it just gets code contributions
from volunteers. And many people working right now on PHP have their
salaries paid by major companies, like IBM, Microsoft, Oracle, Facebook
and so on. Some of them are paid specifically for doing PHP-related
stuff, AFAIK. We had a number of extensions which development was
initiated and/or sponsored by various companies. Could you explain what
"developed at php.net" really means? If I develop some extension on my
laptop and then commit it to git - is is "developed at php.net" or not?
extensions thats in the core today was not developed somewhere at
php.net, or was either in PECL first? What I'm saying is that I think
it should go to PECL first before getting adapted into the core, no
matter who or where it was developed from if it was not developed
here, yes I realize I make it sound like an alien artifact as Zeev
said.
If the problem is that it wasn't in PECL - the RFC says "As the code
becomes available, put it in PECL.". Once that happens, we can discuss
moving it to core - as an extension - should be in 5.5 or later. PECL is
not going away and is the first step anyway.
It seems like what you're saying is that it should be in PECL at least
for a year before it can be merged (please correct me if I'm wrong
here). Now, I can see how it could be for an extension whose usage and
stability is uncertain - we don't know yet if a parser for foobar
protocol is needed or if it actually works, so let's put it in PECL and
wait and see. However, here we know it (bytecode caching) is needed and
this extension has been worked on for many years. Still, if you have
concerns about it - it will be placed in PECL, you could see it and then
make your judgement about schedule and such.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Following the discussion at the end of last week, I prepared a draft
RFC for the inclusion of Optimizer+ in PHP.In parallel we’re in the process of prepping the source code for
independent public consumption, which I hope we can be done with by
the end of next week, hopefully sooner.https://wiki.php.net/rfc/optimizerplus
Comments welcome!
I like it. It would be totally awesome if it came with a webinar or
something where Dmitry/Stas explain how it works though. Understanding
how APC works has always been a contentious point. I'd be awesome if we
could turn that around with O+?
cheers,
Derick
Am 29.01.2013 16:54, schrieb Derick Rethans:
I like it. It would be totally awesome if it came with a webinar or
something where Dmitry/Stas explain how it works though. Understanding
how APC works has always been a contentious point. I'd be awesome if we
could turn that around with O+?
I think it is a good thing that Zend open sources their bytecode cache.
And I think that what Derick proposes is a brilliant idea.
--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
Following the discussion at the end of last week, I prepared a draft
RFC for the inclusion of Optimizer+ in PHP.In parallel we’re in the process of prepping the source code for
independent public consumption, which I hope we can be done with by
the end of next week, hopefully sooner.https://wiki.php.net/rfc/optimizerplus
Comments welcome!
I like it. It would be totally awesome if it came with a webinar or
something where Dmitry/Stas explain how it works though. Understanding
how APC works has always been a contentious point. I'd be awesome if we
could turn that around with O+?
I'm sure we can arrange that.
Zeev
Following the discussion at the end of last week, I prepared a draft
RFC for the inclusion of Optimizer+ in PHP.In parallel we’re in the process of prepping the source code for
independent public consumption, which I hope we can be done with by
the end of next week, hopefully sooner.https://wiki.php.net/rfc/optimizerplus
Comments welcome!
I like it. It would be totally awesome if it came with a webinar or
something where Dmitry/Stas explain how it works though. Understanding
how APC works has always been a contentious point. I'd be awesome if we
could turn that around with O+?I'm sure we can arrange that.
Well, a webinar is nice and shiny but I would rather see them spend
time on writing a very good documentation instead. Much more useful
and can be updated easily.
Cheers,
Pierre
@pierrejoye
Sent from my iPhone 6 Beta [Confidential use only]
Following the discussion at the end of last week, I prepared a draft
RFC for the inclusion of Optimizer+ in PHP.In parallel we’re in the process of prepping the source code for
independent public consumption, which I hope we can be done with by
the end of next week, hopefully sooner.https://wiki.php.net/rfc/optimizerplus
Comments welcome!
I like it. It would be totally awesome if it came with a webinar or
something where Dmitry/Stas explain how it works though. Understanding
how APC works has always been a contentious point. I'd be awesome if we
could turn that around with O+?I'm sure we can arrange that.
Well, a webinar is nice and shiny but I would rather see them spend
time on writing a very good documentation instead. Much more useful
and can be updated easily.Cheers,
Pierre
@pierrejoye
--
As just a normal user without any voting rights, I recognize that integrating O+ would be a major improvement for PHP and should be incorporated in core as soon as possible.
If it only takes 2 months, go for it, userland cache would be really awesome to have but an opcode cache in core is far better.
APC is already very difficult to manage and integrate (6+ months), so why not integrate O+ in the first place and in the next PHP release an userland cache space? It could be a simplified and easier-to-maintain APC version and it would help to keep everything as modular as possible.
Greetings.
Hi!
I like it. It would be totally awesome if it came with a webinar or
something where Dmitry/Stas explain how it works though. Understanding
how APC works has always been a contentious point. I'd be awesome if we
could turn that around with O+?
Once the code is out there, I think it's definitely possible.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--e89a8fb1f5b0f501b204d468d53f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printableAll,
Following the discussion at the end of last week, I prepared a draft RFC
for the inclusion of Optimizer+ in PHP.In parallel we=E2=80=99re in the process of prepping the source code for
independent public consumption, which I hope we can be done with by the end
of next week, hopefully sooner.https://wiki.php.net/rfc/optimizerplus
Comments welcome!
As already said in this thread, the major issue for 5.4 adaption was APC, so I really
like that we get a 5.5 compatible optimizer. We are planning to go into beta mode
next week which is a feature freeze. Therefore optimizer would not make it in, but I
think as the code is already mature and not just a random new feature I think we can
allow this into core during beta phase, maybe for 5.5 disabled by default. Anyhow
we are already late with 5.5.0 and I dont want a 5.5.0 release in May.
David
Following the discussion at the end of last week, I prepared a draft RFC
for the inclusion of Optimizer+ in PHP.
In parallel we’re in the process of prepping the source code for
independent public consumption, which I hope we can be done with by the end
of next week, hopefully sooner.
Following the discussion at the end of last week, I prepared a draft RFC
for the inclusion of Optimizer+ in PHP.In parallel we’re in the process of prepping the source code for
independent public consumption, which I hope we can be done with by the end
of next week, hopefully sooner.
It's great news that Zend Technologies has decided to open-source
Optimizer+ and given that it is now "the end of next week I look
forward to seeing on this code any day. So thanks to you for this
decision. But now to specific comments on your RFC.
- Scope of the RFC.
IMO, the RFC covers four separate issues that would be easier to review,
refine and agree if they were kept separate:
a. Zend's decision to OS+. This is entirely within Zend Technology Inc.
and outside the scope of any RFC.
b. The establishment and proper architecture and support of an
opcode-cache interface within the Zend Execution Engine (EE). I will
discuss this below.
c. The decision to include Optimizer+ as a core extension within the
PHP project. However as at the time of this draft only Zend employees
-- and selected Zend-approved 2nd parties who have signed the
appropriate NDAs -- have access to the Optimizer+ source and are
therefore able to review its content. Surely such open access is a
precondition, and it makes no sense to issue an RFC to inform this
decision until at least a few months after the source has been made
widely available for review.
d. The project decision to give any specific opcode-cache extension a
"preferred" status over the alternative opcode-caches. Such a decision
is going to be contentious and -- unless carefully, transparently and
fairly managed -- could lead to conflict within the project. Not good.
So I would suggest that the RFC limit itself to non-contentious claims
relating to one optimizer performance over another.
- The Detailed Content
The Introduction will need redrafting depending on the proposed /
revised scope of this RFC.
Some form of definition / description of both a PHP opcode-cache and PHP
data-cache needs including in the PHP wiki, but this would sit better
under the https://wiki.php.net/internals hierarchy. This RFC should
simply wiki-link to this page on the first use of [[opcode cache]].
The "Interaction with other extensions and plugins" section is surely
a general statement of requirement that should apply to any opcode
cache and not just Optmizer+, so again this content belongs in separate
Wiki a document with a wiki-link here.
The "Alternatives" is really a "Comparison of APC and Optimizer+" and I
suggest that some points are contentious. The same point applies to the
remaining sections. Surely this sort of comparison only becomes
necessary when we've reach a stage where we are asking voters to choose
a preferred cache, and in that case wouldn't be more appropriate to
agree the selection / assessment criteria first before carrying out a
selection exercise?
- Why do I suggest an Opcode-Cache interface RFC?
The current Zend 2.x engines provide some hooks which enable the main
opcode caches -- including Optimizer+ and APC -- to deliver accelerated
performance for many application usecases. However, some aspects of
hooking an opcode cache into the Zend EE remain a somewhat of a
compromise. These include:
a. The management of early vs. late binding and the work-arounds that
opcode caches must do to back-out unwanted early binding.
b. Some essential functions that the caches must hook into are not
exposed as hooks (like zend_compile_file) and are sometime implemented
using static functions, leading to the cache needing to reimplement
chunks of zend code.
c. There should be a clear scoping separation of what the (cached)
compile does and what the EE does. An example of where this is mixed is
in the ZEND_INCLUDE_OR_EVAL_xxx_HANDLER functions which resolve paths
and open source files in the case of the xxx_once functions. This file
access is usually unnecessary in the case of cached files as the op-code
cache has already cached the relevant information.
Given that opcode caches are now core to PHP performance, it should be
possible to implement a cache using hooks and interfaces exported
through a Zend header file and without recoding bits of the engine.
Optimizer+ should be an exemplar of such an approach.
Regards Terry Ellison
hi Zeev,
Any news on this front?
It's becoming harder and harder to consider it in 5.5 if we have to
wait longer. There are enough volunteers to help, open it now :)
Cheers,
Pierre
We're trying to do exactly that. It's taking a bit longer than expected
but I'm hopeful we'll open the initial code base tomorrow.
Zeev
-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Tuesday, February 12, 2013 3:48 PM
To: Zeev Suraski
Cc: PHP internals
Subject: Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP
distributionhi Zeev,
Any news on this front?
It's becoming harder and harder to consider it in 5.5 if we have to wait
longer.
There are enough volunteers to help, open it now :)Cheers,
Pierre
We're trying to do exactly that. It's taking a bit longer than expected
but I'm hopeful we'll open the initial code base tomorrow.Zeev
-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Tuesday, February 12, 2013 3:48 PM
To: Zeev Suraski
Cc: PHP internals
Subject: Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP
distributionhi Zeev,
Any news on this front?
It's becoming harder and harder to consider it in 5.5 if we have to wait
longer.
There are enough volunteers to help, open it now :)Cheers,
Pierre--
My weekend is reserved for testing!
Regards,
Thomas