For your browsing pleasure:
https://github.com/zend-dev/ZendOptimizerPlus/
An initial README with some instructions is available at
http://bit.ly/VSs5KC
We’ve put it under the PHP license, with the same PHP Group copyright
header as all files in PHP.
As per Derick’s idea, we can arrange a webinar for those interested in
better understanding how it works. Note that this will not be a webinar
for the faint of heart – opcode caches are complicated pieces of software;
Attendees should have very good engine-development knowledge to have a good
chance of understanding what’s going on… Stas – your help in that webinar
would be very welcome J
Zeev
For your browsing pleasure:
https://github.com/zend-dev/ZendOptimizerPlus/
An initial README with some instructions is available at
http://bit.ly/VSs5KCWe’ve put it under the PHP license, with the same PHP Group copyright
header as all files in PHP.As per Derick’s idea, we can arrange a webinar for those interested in
better understanding how it works. Note that this will not be a webinar
for the faint of heart – opcode caches are complicated pieces of software;
Attendees should have very good engine-development knowledge to have a good
chance of understanding what’s going on… Stas – your help in that webinar
would be very welcome JZeev
Great !
I'm in for the webinar !
Julien.Pauli
Me too :)
For your browsing pleasure:
https://github.com/zend-dev/ZendOptimizerPlus/
An initial README with some instructions is available at
http://bit.ly/VSs5KCWe’ve put it under the PHP license, with the same PHP Group copyright
header as all files in PHP.As per Derick’s idea, we can arrange a webinar for those interested in
better understanding how it works. Note that this will not be a webinar
for the faint of heart – opcode caches are complicated pieces of
software;
Attendees should have very good engine-development knowledge to have a
good
chance of understanding what’s going on… Stas – your help in that
webinar
would be very welcome JZeev
Great !
I'm in for the webinar !
Julien.Pauli
That's a good idea :) I'm also in
As per Derick’s idea, we can arrange a webinar for those interested in
better understanding how it works.
As per Derick’s idea, we can arrange a webinar for those interested in
better understanding how it works. Note that this will not be a webinar
for the faint of heart – opcode caches are complicated pieces of software;
Attendees should have very good engine-development knowledge to have a good
chance of understanding what’s going on… Stas – your help in that webinar
would be very welcome J
I'm interested in attending the webinar, as well, Zeev. Any
general idea when it would be (e.g. - next week, March, sometime
during the summer)?
+1 for webinar
2013/2/13 Zeev Suraski zeev@zend.com
For your browsing pleasure:
https://github.com/zend-dev/ZendOptimizerPlus/
An initial README with some instructions is available at
http://bit.ly/VSs5KCWe’ve put it under the PHP license, with the same PHP Group copyright
header as all files in PHP.As per Derick’s idea, we can arrange a webinar for those interested in
better understanding how it works. Note that this will not be a webinar
for the faint of heart – opcode caches are complicated pieces of software;
Attendees should have very good engine-development knowledge to have a good
chance of understanding what’s going on… Stas – your help in that webinar
would be very welcome JZeev
For your browsing pleasure:
https://github.com/zend-dev/ZendOptimizerPlus/
An initial README with some instructions is available at
http://bit.ly/VSs5KCWe’ve put it under the PHP license, with the same PHP Group copyright
header as all files in PHP.As per Derick’s idea, we can arrange a webinar for those interested in
better understanding how it works. Note that this will not be a webinar
for the faint of heart – opcode caches are complicated pieces of software;
Attendees should have very good engine-development knowledge to have a good
chance of understanding what’s going on… Stas – your help in that webinar
would be very welcome JZeev
Thanks Zeev. I've pulled a copy and will review with interest //Terry
Le 13/02/2013 15:51, Zeev Suraski a écrit :
Great News !
Do you know if any control panel (like the one provided with APC)
already exists ?
I notice accelerator_reset, accelerator_get_configuration and
accelerator_get_status functions, so should be possible.
Regards,
Remi.
P.S. RPM already available in my repo for Fedora / RHEL / CentOS users
of php 5.4 and Fedora users of php 5.5.
For your browsing pleasure:
https://github.com/zend-dev/ZendOptimizerPlus/
An initial README with some instructions is available at
http://bit.ly/VSs5KCWe’ve put it under the PHP license, with the same PHP Group copyright
header as all files in PHP.
Great to see.
The README covers much of the content (and in more detail) that I
previously wanted to see in the RFC.
There are some things still missing from the RFC, though:
-
do you see Optimizer+ being enabled (if not in PECL) or disabled by
default, etc. -
your email comment to John Carter about Zend Guard decoder
-
There are still open questions in the RFC; these need to be closed
before voting.
Comments:
-
The README gives recommended parameters. Taking that advice at
face value, I think these should be default settings. -
Should the name reflect the code's main purpose (op-code caching),
and allowing a future use of "optimizer" for a more sophisticated
optimizer implementation? Or do you see Optimizer+ being the
framework for such optimizations?
Questions (I haven't dug through the code):
-
What do CLI processes share?
-
Is there an architectural reason why the 'embed' embedded SAPI
couldn't be supported? (Lack of parent forking??)
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
Great to see.
The README covers much of the content (and in more detail) that I
previously
wanted to see in the RFC.
Excellent!
There are some things still missing from the RFC, though:
- do you see Optimizer+ being enabled (if not in PECL) or disabled by
default, etc.
I think we should strive to have it enabled by default, but it should
definitely be possible to turn it off too. I guess that can be another
voting possibility - bundle & turn on by default (vs. just bundle).
- your email comment to John Carter about Zend Guard decoder
We don't want to create any special cases in O+; We would either take care
of integrating it by having slightly patching our O+ build, or we'd add
generalized facilities to O+ that will allow the loader to interact with it
directly (that would not be unique to the Zend loader but could be used by
any extension). From my point of view, it's nice-to-have to solve it before
5.5.0, not a must-have.
- There are still open questions in the RFC; these need to be closed
before voting.
I think the only open question is integration with other modules, most
notably debuggers. This is something we'd like to tackle sooner rather than
later, and I think it'll be easier to just go ahead and do that now that the
source code is available. Any other open questions that need answering?
Comments:
- The README gives recommended parameters. Taking that advice at
face value, I think these should be default settings.
The default settings are designed to minimize the chance that an app or a
workflow - which worked fine w/o O+ - will suddenly fail after O+ is
installed. The 'recommended' settings are for max-performance. You can
view it like 'Safe' vs. 'Extreme' settings. Personally I think the default
settings should be closer to the Safe ones...
- Should the name reflect the code's main purpose (op-code caching),
and allowing a future use of "optimizer" for a more sophisticated
optimizer implementation? Or do you see Optimizer+ being the
framework for such optimizations?
O+ does perform some optimizations in addition to caching code, in a pretty
sophisticated manner actually (block optimizations). Optimizations - which
can be expensive to carry out - are definitely a good fit with an opcode
cache, that ensures that you wouldn't have to do these optimizations more
than once. I'm obviously subjective but I think the name Optimizer+ does a
good job at suggesting that it's both an Optimizer but also something else.
Perhaps we should call it OptiCache? :)
Questions (I haven't dug through the code):
- What do CLI processes share?
IIRC nothing, presently it's not very useful for CLI except for testing
(it'll only apply to a single run). I could be wrong though, Dmitry?
- Is there an architectural reason why the 'embed' embedded SAPI
couldn't be supported? (Lack of parent forking??)
As long as we can map the shared memory piece to the same base address,
there's no inherent reason why we couldn't make it work with SAPI/embed.
That's how we work on Windows where there's no concept of fork(); We could
apply a similar concept on Linux - although note that it's not 100%
reliable, a base address that's free in one process may not be available in
another...
Zeev
O+ does perform some optimizations in addition to caching code, in a pretty
sophisticated manner actually (block optimizations). Optimizations - which
can be expensive to carry out - are definitely a good fit with an opcode
cache, that ensures that you wouldn't have to do these optimizations more
than once. I'm obviously subjective but I think the name Optimizer+ does a
good job at suggesting that it's both an Optimizer but also something else.
Perhaps we should call it OptiCache? :)Questions (I haven't dug through the code):
- What do CLI processes share?
IIRC nothing, presently it's not very useful for CLI except for testing
(it'll only apply to a single run). I could be wrong though, Dmitry?
Well, if it does block-level optimizations, that is already enough to
make it useful for CLI-scripts, as even though caching is not relevant
for long-running processes, optimizations should make things faster.
Are optimizations documented?
--
Alexey Zakhlestin,
http://github.com/indeyets
Hi!
Well, if it does block-level optimizations, that is already enough to
make it useful for CLI-scripts, as even though caching is not relevant
for long-running processes, optimizations should make things faster.
For most scripts, optimizations are not really worth it unless you run
the same code over and over, so for CLI it would be noticeable only if
you run long-running CPU-intensive server.
Are optimizations documented?
Not yet AFAIK.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
On Thursday 14 February 2013 10:24:22 Stas Malyshev wrote:
For most scripts, optimizations are not really worth it unless you run
the same code over and over, so for CLI it would be noticeable only if
you run long-running CPU-intensive server.
Apart from the long-running servers, there is also cronjobs. I have quite a
number of them running on some of my servers, some of them once per minute,
and they all share a certain number of classes between them. I imagine their
startup and execution could profit a bit from an opcode cache.
What keeps an opcode cache from using a persistent memory mapped file, maybe
one per UID for security reasons, to cache opcodes from separate CLI
invocations?
best regards
Patrick
Are optimizations documented?
Not yet AFAIK.
No, but they are pretty self-explanatory. O+ is a Zend extension
rather than a PHP extension and this enables it to exploit extra
hooks (see the tail of ZendAccelerator.c) and specifically follow
through accel_op_array_handler() and the routines in the Optimizer
subdirectory. Essentially this hook is invoked as an epilogue to the
generating of any op_array. What this does is a number of peephole
optimizisations to simplify and NOP out instruction sequences, and the
last pass compresses the code removing dead NOPs to shrink the op_array
-- this is typical of the sorts of things that the optimization passes
of a compiler would do.
And this is a segue into one architectural issue the immediately struck
me on scanning the code: surely there is a natural domain separation
between compilation, image startup/rundown, and execution. (i) is
optimally done once per S/W version, (ii) per request, (iii) per
instruction executed. Surely O+ is currently a hybrid of (i) and (ii)
and whilst this might have occurred for understandable historical
reasons, I question this rationale going forward.
(A) The op-code optimization should be integrated into the core compiler
and enabled through a GC(compiler_option) to be available to any
opcode cache -- or to the application designer (by exposing these
options through an INI directive.
(B) The O+ opcode cache itself is logically quite separate. It makes
great sense to keep ithis as a Zend extension (given the desire from
some of the dev team to maintain a clear logical separation between the
upper PHP environment and the Zend, Hippop, ... execution environments
that support it). A Zend opcode cache belongs firmly in the Zend world
and shouldn't be a PHP extension.
I also note some interesting difference in approaches between O+ and
APC, say for example:
-
in the handling of the ZEND_INCLUDE_OR_EVAL instruction where APC
patches the op handler and O+ does peephole opcode examination. Both
these workarounds could be avoided by tidying up the scope of work in
the instruction code. -
in the treatment of early binding class inheritence: APC include some
reasonably complex logic to back this out; O+ sets a compiler option to
disable this inheritance occurring in the first place, an approach that
APC might want to copy.
Hi!
(A) The op-code optimization should be integrated into the core compiler
and enabled through a GC(compiler_option) to be available to any
opcode cache -- or to the application designer (by exposing these
options through an INI directive.
Most optimizations would not give perceivable benefit unless the
optimized code is run many times. So enabling it without opcode cache
would not produce very big benefit. But yes, in theory these code parts
can live separately and they don't actually need each other.
that support it). A Zend opcode cache belongs firmly in the Zend world
and shouldn't be a PHP extension.
I must say I don't understand this conclusion.
I also note some interesting difference in approaches between O+ and
APC, say for example:
- in the handling of the ZEND_INCLUDE_OR_EVAL instruction where APC
patches the op handler and O+ does peephole opcode examination. Both
these workarounds could be avoided by tidying up the scope of work in
the instruction code.
Could you explain this a bit more?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
(A) The op-code optimization should be integrated into the core compiler
and enabled through a GC(compiler_option) to be available to any
opcode cache -- or to the application designer (by exposing these
options through an INI directive.
Most optimizations would not give perceivable benefit unless the
optimized code is run many times. So enabling it without opcode cache
would not produce very big benefit. But yes, in theory these code parts
can live separately and they don't actually need each other.
My point here is that APC and the other opcode caches would also benefit
from these optimizations; they really belong to the compiler and not to
an opcode accelerator. Also yes, this type of optimisation usually has
no net benefit unless #runs / compile is much greater than one, however
there are scenarios (e.g. some nasty iteration intensive batch process)
where taking the hit on optimisation still produces a net runtime saving.
that support it). A Zend opcode cache belongs firmly in the Zend world
and shouldn't be a PHP extension.
I must say I don't understand this conclusion.
Put simply PHP extensions should only reference the APIs exposed in the
php headers. Zend has its own interface and extensions and since a Zend
Opcode cache is SO intimately coupled with the Zend environment it makes
sense to use a Zend extension to implement this. The whole idea of
opcode caching just isn't relevant to a Hiphop environment or even for
that matter a CLR or Java one since this do their own internal caching
anyway.I also note some interesting difference in approaches between O+ and
APC, say for example:
- in the handling of the ZEND_INCLUDE_OR_EVAL instruction where APC
patches the op handler and O+ does peephole opcode examination. Both
these workarounds could be avoided by tidying up the scope of work in
the instruction code.
Could you explain this a bit more?
As I posted in a separate not to this list, I've am developing my own
LPC extension, a fork of APC optimized for CLI and GCI use. The dogma
here is that there is no point in opcode caching because "performance
isn't a driver". Well my experience is that performance is always a
driver For example, just because your application is running on a
shared service where UID enforced security must be applied and therefore
some form of scalable per-UID execution environment must be used doesn't
mean that you don't care about performance. LPC still give a ~ 2x
throughput improvement on MediaWiki for example.
I forked and rewrote this cache extension because I couldn't stretch the
APC code to do what I want in a performant manner without breaking it.
It's a demonstrator to help me understand the real issues here and to
get to grips with the minutiae of PHP caching technologies. I just
don't see this ever getting to production, but I must admit that
regressing some of this technologies onto O+ is an option that interests
me because this does hold out the potential of a standard optimiser
extension that supports all mainstream SAPIs.
Now to ZEND_INCLUDE_OR_EVAL. My rationale here is that if the admin has
specified a stat=0 (or equiv) option then this is a statement that the
caches content and metadata can be trusted so there is no point in
examining or reading source files. However, in the case of the xxx_once
variants of this instruction, the
ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER() does path resolution and in
the case of first load opens the source stream. Why? Why not just
leave examination of the source stream to the compile function? LPC
(like APC though for different reasons) has to rehook the
ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLE() handler with a wrapper that
does dynamic code modification to prevent this access occurring. O+
adopts a different strategy.
LPC or APC having to walk through and essential patch over (private)
static constant op_handler vectors is just plain horrible. No, IMO the
Zend architecture should be designed to support caching; it should
present a proper clean interface that extensions such as O+ and APC
implement; and the entire PHP test suite should be capable of being
executed with a cache extension in place and a good cache should not
introduce any test failures.
Sorry for the rant and I hope that I answered your Q :)
Hi!
Put simply PHP extensions should only reference the APIs exposed in the
php headers. Zend has its own interface and extensions and since a Zend
Opcode cache is SO intimately coupled with the Zend environment it makes
sense to use a Zend extension to implement this. The whole idea of
OK, I see. Well, the difference between Zend ext and PHP ext is not that
big, it's mostly just loading order and couple of hooks, of which I
think O+ really uses only op_array_handler, and this for optimization's
benefit - so if you separate optimization, I think O+ can live as PHP
extension, maybe. Not sure if it's worth the trouble though.
Now to ZEND_INCLUDE_OR_EVAL. My rationale here is that if the admin has
specified a stat=0 (or equiv) option then this is a statement that the
caches content and metadata can be trusted so there is no point in
examining or reading source files. However, in the case of the xxx_once
variants of this instruction, the
ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER() does path resolution and in
the case of first load opens the source stream. Why? Why not just
I see what you mean. I can't think of a reason why they are combined
now. Before realpath cache and separate path resolution functions that
was the only way to handle paths properly - since path can be resolved
differently by different streams, etc. I think giving a fresh look to
this API and seeing if we can improve it for 5.6, etc. would probably be
a good idea.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Zeev Suraski in php.internals (Thu, 14 Feb 2013 17:21:48 +0200):
I think the only open question is integration with other modules, most
notably debuggers.
php_ZendOptimizerPlus.dll and php_xdebug.dll loaded both together in PHP
5.3 and PHP 5.4 (x86, TS and NTS). I do not know yet if there are any
issues.
As far as I know there is no php_xdebug.dll yet for PHP 5.5.
Jan
Zeev Suraski in php.internals (Thu, 14 Feb 2013 17:21:48 +0200):
I think the only open question is integration with other modules, most
notably debuggers.php_ZendOptimizerPlus.dll and php_xdebug.dll loaded both together in PHP
5.3 and PHP 5.4 (x86, TS and NTS). I do not know yet if there are any
issues.
Make sure you load ZO before xdebug and it seems to work ok. If you load
xdebug first you will run into interesting problems.
-Rasmus
Rasmus Lerdorf in php.internals (Thu, 14 Feb 2013 11:14:20 -0500):
Zeev Suraski in php.internals (Thu, 14 Feb 2013 17:21:48 +0200):
I think the only open question is integration with other modules, most
notably debuggers.php_ZendOptimizerPlus.dll and php_xdebug.dll loaded both together in PHP
5.3 and PHP 5.4 (x86, TS and NTS). I do not know yet if there are any
issues.Make sure you load ZO before xdebug and it seems to work ok. If you load
xdebug first you will run into interesting problems.
Hmm. I was loading them the other way around, but did not encounter any
interesting problems yet...
Jan
Rasmus Lerdorf in php.internals (Thu, 14 Feb 2013 11:14:20 -0500):
Zeev Suraski in php.internals (Thu, 14 Feb 2013 17:21:48 +0200):
I think the only open question is integration with other modules, most
notably debuggers.php_ZendOptimizerPlus.dll and php_xdebug.dll loaded both together in PHP
5.3 and PHP 5.4 (x86, TS and NTS). I do not know yet if there are any
issues.Make sure you load ZO before xdebug and it seems to work ok. If you load
xdebug first you will run into interesting problems.Hmm. I was loading them the other way around, but did not encounter any
interesting problems yet...
Most things work fine, but I hit a weird segfault in some complicated
code which I fixed by flipping the order.
-Rasmus
Rasmus Lerdorf in php.internals (Thu, 14 Feb 2013 11:32:55 -0500):
Make sure you load ZO before xdebug and it seems to work ok. If you load
xdebug first you will run into interesting problems.Most things work fine, but I hit a weird segfault in some complicated
code which I fixed by flipping the order.
Was that on Windows or on Linux?
Jan
Rasmus Lerdorf in php.internals (Thu, 14 Feb 2013 11:14:20 -0500):
Zeev Suraski in php.internals (Thu, 14 Feb 2013 17:21:48 +0200):
I think the only open question is integration with other modules, most
notably debuggers.php_ZendOptimizerPlus.dll and php_xdebug.dll loaded both together in
PHP
5.3 and PHP 5.4 (x86, TS and NTS). I do not know yet if there are any
issues.Make sure you load ZO before xdebug and it seems to work ok. If you load
xdebug first you will run into interesting problems.Hmm. I was loading them the other way around, but did not encounter any
interesting problems yet...Most things work fine, but I hit a weird segfault in some complicated
code which I fixed by flipping the order.
Shouldn't we document that, or add some notice at extension loading by
detecting Xdebug ?
Julien.Pauli
- Should the name reflect the code's main purpose (op-code caching),
and allowing a future use of "optimizer" for a more sophisticated
optimizer implementation? Or do you see Optimizer+ being the
framework for such optimizations?O+ does perform some optimizations in addition to caching code, in a pretty
sophisticated manner actually (block optimizations). Optimizations - which
can be expensive to carry out - are definitely a good fit with an opcode
cache, that ensures that you wouldn't have to do these optimizations more
than once. I'm obviously subjective but I think the name Optimizer+ does a
good job at suggesting that it's both an Optimizer but also something else.
Perhaps we should call it OptiCache? :)
If this will go into PECL first then I see no reason to change the name
from Optimizer+. If this will go into PHP then it shouldn't need a name at
all, should it? It could just be "opcode cache" (--enable-opcode-cache /
--disable-opcode-cache). That seems more descriptive to me then some fancy
name like "Optimizer+". Regarding the optimizations it contains, imho those
are a separate concern and if Optimizer+ goes into core both aspects should
be cleanly separated (and you should be able to enable/disable them
separately). The optimizations are not directly related to caching. Caching
makes them more viable for web requests, but as someone already pointed out
the optimizations are also useful on CLI, where compile times just aren't a
concern anyway (but run times can be).
Btw, I was quite surprised to see the block optimizations in O+ :) Really
cool!
Nikita
- Should the name reflect the code's main purpose (op-code caching),
and allowing a future use of "optimizer" for a more sophisticated
optimizer implementation? Or do you see Optimizer+ being the
framework for such optimizations?O+ does perform some optimizations in addition to caching code, in a pretty
sophisticated manner actually (block optimizations). Optimizations - which
can be expensive to carry out - are definitely a good fit with an opcode
cache, that ensures that you wouldn't have to do these optimizations more
than once. I'm obviously subjective but I think the name Optimizer+ does a
good job at suggesting that it's both an Optimizer but also something else.
Perhaps we should call it OptiCache? :)If this will go into PECL first then I see no reason to change the name
from Optimizer+. If this will go into PHP then it shouldn't need a name at
all, should it? It could just be "opcode cache" (--enable-opcode-cache /
--disable-opcode-cache). That seems more descriptive to me then some fancy
name like "Optimizer+". Regarding the optimizations it contains, imho those
are a separate concern and if Optimizer+ goes into core both aspects should
be cleanly separated (and you should be able to enable/disable them
separately). The optimizations are not directly related to caching. Caching
makes them more viable for web requests, but as someone already pointed out
the optimizations are also useful on CLI, where compile times just aren't a
concern anyway (but run times can be).
I usually don't chime in with 'me too' comments, but I think Nikita
summed it up nicely.
> - Should the name reflect the code's main purpose (op-code caching), > and allowing a future use of "optimizer" for a more sophisticated > optimizer implementation? Or do you see Optimizer+ being the > framework for such optimizations? O+ does perform some optimizations in addition to caching code, in a pretty sophisticated manner actually (block optimizations). Optimizations - which can be expensive to carry out - are definitely a good fit with an opcode cache, that ensures that you wouldn't have to do these optimizations more than once. I'm obviously subjective but I think the name Optimizer+ does a good job at suggesting that it's both an Optimizer but also something else. Perhaps we should call it OptiCache? :)If this will go into PECL first then I see no reason to change the name from Optimizer+. If this will go into PHP then it shouldn't need a name at all, should it? It could just be "opcode cache" (--enable-opcode-cache / --disable-opcode-cache). That seems
more descriptive to me then some fancy name like "Optimizer+". Regarding the optimizations it contains, imho those are a separate concern and if Optimizer+ goes into core both aspects should be cleanly separated (and you should be able to enable/disable
them separately). The optimizations are not directly related to caching. Caching makes them more viable for web requests, but as someone already pointed out the optimizations are also useful on CLI, where compile times just aren't a concern anyway (but run
times can be).
This raises questions for Zeev to address.
Btw, I was quite surprised to see the block optimizations in O+ :) Really cool!
Nikita
The php.ini parameters will likely need a name (or two - if the optimizer is distinct from the op-code cache) as a prefix.
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
Great to see.
The README covers much of the content (and in more detail) that I
previously
wanted to see in the RFC.Excellent!
There are some things still missing from the RFC, though:
- do you see Optimizer+ being enabled (if not in PECL) or disabled by
default, etc.I think we should strive to have it enabled by default, but it should
definitely be possible to turn it off too. I guess that can be another
voting possibility - bundle & turn on by default (vs. just bundle).
To avoid too many voting choices, I think this can be decided outside
the RFC process.
- your email comment to John Carter about Zend Guard decoder
We don't want to create any special cases in O+; We would either take care
of integrating it by having slightly patching our O+ build, or we'd add
generalized facilities to O+ that will allow the loader to interact with it
directly (that would not be unique to the Zend loader but could be used by
any extension). From my point of view, it's nice-to-have to solve it before
5.5.0, not a must-have.
This should still be stated in the RFC. (The PHP community suffers
from poor RFCs. Since you are a leader in the PHP community, your RFC
should set a good example.)
- There are still open questions in the RFC; these need to be closed
before voting.I think the only open question is integration with other modules, most
notably debuggers. This is something we'd like to tackle sooner rather than
later, and I think it'll be easier to just go ahead and do that now that the
source code is available. Any other open questions that need
answering?
I think this should be reworded before the vote occurs. I'm fine with
leaving it under a heading "for future investigation", i.e. stating it
won't happen in an initial release.
Comments:
- The README gives recommended parameters. Taking that advice at
face value, I think these should be default settings.The default settings are designed to minimize the chance that an app or a
workflow - which worked fine w/o O+ - will suddenly fail after O+ is
installed. The 'recommended' settings are for max-performance. You can
view it like 'Safe' vs. 'Extreme' settings. Personally I think the default
settings should be closer to the Safe ones...
We can probably meet in the middle: leave the hard coded defaults as
they currently are, and use those values in the php.ini-development
examples. Php.ini-production can have the values recommended in the
README. (Giving the proposed php.ini settings is another thing the
RFC should have...)
- Should the name reflect the code's main purpose (op-code caching),
and allowing a future use of "optimizer" for a more sophisticated
optimizer implementation? Or do you see Optimizer+ being the
framework for such optimizations?O+ does perform some optimizations in addition to caching code, in a pretty
sophisticated manner actually (block optimizations). Optimizations - which
can be expensive to carry out - are definitely a good fit with an opcode
cache, that ensures that you wouldn't have to do these optimizations more
than once. I'm obviously subjective but I think the name Optimizer+ does a
good job at suggesting that it's both an Optimizer but also something else.
Perhaps we should call it OptiCache? :)
It seems a good time to disambiguate its relationship to any current
or future Zend product.
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
-----Original Message-----
From: Christopher Jones [mailto:christopher.jones@oracle.com]
Sent: Thursday, February 14, 2013 9:25 PM
To: Zeev Suraski
Cc: PHP internals
Subject: Re: [PHP-DEV] Zend Optimizer+ Source Code now availableGreat to see.
The README covers much of the content (and in more detail) that I
previously wanted to see in the RFC.Excellent!
There are some things still missing from the RFC, though:
- do you see Optimizer+ being enabled (if not in PECL) or disabled
by
default, etc.I think we should strive to have it enabled by default, but it
should definitely be possible to turn it off too. I guess that can be
another voting possibility - bundle & turn on by default (vs. just
bundle).To avoid too many voting choices, I think this can be decided outside the
RFC
process.
That depends on whether there'll be apparent consensus about it; But it can
wait until after that RFC is approved, as a separate discussion and if
needed a separate vote.
We don't want to create any special cases in O+; We would either take
care of integrating it by having slightly patching our O+ build, or
we'd add generalized facilities to O+ that will allow the loader to
interact with it directly (that would not be unique to the Zend loader
but could be used by any extension). From my point of view, it's
nice-to-have to solve it before 5.5.0, not a must-have.This should still be stated in the RFC. (The PHP community suffers from
poor
RFCs. Since you are a leader in the PHP community, your RFC should set a
good
example.)
I think it goes beyond of the scope of the RFC but I'll add a bit of blurb
there.
- There are still open questions in the RFC; these need to be closed
before voting.I think the only open question is integration with other modules, most
notably debuggers. This is something we'd like to tackle sooner
rather than later, and I think it'll be easier to just go ahead and do
that now that the source code is available. Any other open questions
that need answering?I think this should be reworded before the vote occurs. I'm fine with
leaving it
under a heading "for future investigation", i.e. stating it won't happen
in an
initial release.
OK.
Comments:
- The README gives recommended parameters. Taking that advice at
face value, I think these should be default settings.The default settings are designed to minimize the chance that an app
or a workflow - which worked fine w/o O+ - will suddenly fail after O+
is installed. The 'recommended' settings are for max-performance.
You can view it like 'Safe' vs. 'Extreme' settings. Personally I
think the default settings should be closer to the Safe ones...We can probably meet in the middle: leave the hard coded defaults as they
currently are, and use those values in the php.ini-development examples.
Php.ini-production can have the values recommended in the README. (Giving
the proposed php.ini settings is another thing the RFC should have...)
I actually think that the differences between the 'safe' and 'extreme'
settings don't correspond too well to development vs. production. They
depend on the nature of the code/app you're running, and not on whether
you're developing the code or running it in production.
In my opinion, the defaults should be more or less the defaults we have
today, perhaps with minor tweaks - but with the guiding principle being that
they need to be safe, and minimize the chance that semantics would change
if you enable/disable O+.
The 'recommended' settings, which should really read 'extreme performance
settings', should end up in a documentation section, with nice clear
warnings about each and every setting and its potential impact on how apps
will perform.
I'll clarify that in the RFC.
- Should the name reflect the code's main purpose (op-code caching),
and allowing a future use of "optimizer" for a more sophisticated
optimizer implementation? Or do you see Optimizer+ being the
framework for such optimizations?O+ does perform some optimizations in addition to caching code, in a
O+ pretty
sophisticated manner actually (block optimizations). Optimizations -
which can be expensive to carry out - are definitely a good fit with
an opcode cache, that ensures that you wouldn't have to do these
optimizations more than once. I'm obviously subjective but I think
the name Optimizer+ does a good job at suggesting that it's both an
Optimizer
but also something else.
Perhaps we should call it OptiCache? :)It seems a good time to disambiguate its relationship to any current or
future
Zend product.
Agreed. Rasmus and I ping ponged some names and we may want to go with
something more generic along the lines of 'OpCache'. It's shorter than the
"zend_optimizerplus." prefix we currently have for INI directives; It has
the strong implication that it's mostly about caching opcodes; And we could
also mention that 'Op' also originates in the Optimizer Plus component this
was based on.
I suggest that we decouple the decision on naming from the decision on
inclusion; There's clear agreement on my part that we can name it
differently from 'Zend Optimizer+' so it'd be just a matter of finding a
name everyone (or a majority at least) of people are happy with.
Updated RFC: https://wiki.php.net/rfc/optimizerplus
Zeev
Hi Zeev,
I think people are keen to see Optimizer+ merged. Hopefully the RFC
can set expectations clear on what the short-term steps will be, and
what the bigger picture might look like. The middle-term tasks will
then work themselves out as we get to them (in true PHP fashion)
-
What does "Integrate Optimizer+ into PHP, but don’t delay 5.5.0 for
it" mean? Does it mean:- Work really had to get it into PHP 5.5.0 with no delay to 5.5?
- Include it in /ext "as-is", i.e. perhaps no ZTS support, or marked EXPERIMENTAL?
- Include it in PHP 5.5.x where x > 0, when Optimizer+ is complete?
The slippage of 5.5 is an issue to some people, so clarity here
would be good.I believe the wider community is expecting the op-code cache to
"just work", so if that's not the case, the RFC should communicate
this clearly. There's also the potential to damage Zend's
reputation if what is released doesn't work well. -
What are your general thoughts about its integration architecture
and the potential for alternative op-code caches to be used? I know
code can always be changed, but what (if any) design will happen
from the start to make this easy? -
Regarding name choice, here are some: ZopCache, Cachze, RunCachze.
Chris
-----Original Message-----
From: Christopher Jones [mailto:christopher.jones@oracle.com]
Sent: Saturday, February 16, 2013 12:54 AM
To: Zeev Suraski
Cc: PHP internals
Subject: RE: [PHP-DEV] Zend Optimizer+ Source Code now availableHi Zeev,
I think people are keen to see Optimizer+ merged. Hopefully the RFC can
set
expectations clear on what the short-term steps will be, and what the
bigger
picture might look like. The middle-term tasks will then work themselves
out as
we get to them (in true PHP fashion)
What does "Integrate Optimizer+ into PHP, but don’t delay 5.5.0 for
it" mean? Does it mean:
- Work really had to get it into PHP 5.5.0 with no delay to 5.5?
- Include it in /ext "as-is", i.e. perhaps no ZTS support, or marked
EXPERIMENTAL?- Include it in PHP 5.5.x where x > 0, when Optimizer+ is complete?
The slippage of 5.5 is an issue to some people, so clarity here
would be good.
It's in the context of this, one paragraph above it:
"The question on the table is whether most users would prefer a slightly
later release with an out-of-the-box working opcode cache, or a slightly
earlier release without a compatible opcode cache available for several
additional months."
In other words, this option mean that if we can't integrate it without
delaying 5.5.0, we don't integrate it. By integration I refer to including
something that is production quality, potentially enabled-by-default (TBD),
that everyone should feel comfortable using.
I believe the wider community is expecting the op-code cache to
"just work", so if that's not the case, the RFC should communicate
this clearly. There's also the potential to damage Zend's
reputation if what is released doesn't work well.
I agree, although an opcode cache does add an extra layer of complexity, so
it does stand the chance to break otherwise working setups (the same can
happen with other opcode caches). It should be a rare occurrence, with the
performance advantage far outweighing it.
- What are your general thoughts about its integration architecture
and the potential for alternative op-code caches to be used? I know
code can always be changed, but what (if any) design will happen
from the start to make this easy?
I'm not sure. The level of integration we're talking about for 5.5.0, due
to the haste, is not going to be beyond a mostly soft-bundle, at most
something that gets enabled by default - but can still be disabled or
outright removed. That means that you should be able to replace it with any
other opcode cache you might want.
However, for the future, there might be potential for further gains we
might be able to get from tighter integration between the different layers.
At this point I don't have any concrete ideas, though, so it's possible it's
only theoretical. Regardless, such tighter integration - that would
preclude other opcode caches from being used - will have to be the subject
of a separate RFC & vote.
I'll clarify that point too in the RFC.
- Regarding name choice, here are some: ZopCache, Cachze, RunCachze.
Interesting names, I'm curious about pronunciation :)
Zeev
- Regarding name choice, here are some: ZopCache, Cachze, RunCachze.
Interesting names, I'm curious about pronunciation :)
I don't think I would ever get neither the spelling nor the
pronunciation of Cachze right. I like the much simpler "opcache" name.
-Rasmus
- Regarding name choice, here are some: ZopCache, Cachze, RunCachze.
Interesting names, I'm curious about pronunciation :)
I (mostly) pronounce cache the non-American way as "kaysh". Cachze would be like that with a bit of Z sound.
I don't think I would ever get neither the spelling nor the
pronunciation of Cachze right. I like the much simpler "opcache" name.
I agree that unless we get Gopal-like inspiration (inclued, scream) for naming, "opcache" is best.
Chris
-Rasmus
--
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
I agree that unless we get Gopal-like inspiration (inclued, scream) for naming, "opcache" is best.
In the "so bad I can't resist sending it" category is today's
semi-humorous name suggestion: "Cajun". It sounds roughly like the
English pronunciation of "caching"
Sadly it's not as nicely self-documenting as "opcache".
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
I agree that unless we get Gopal-like inspiration (inclued, scream) for naming, "opcache" is best.
In the "so bad I can't resist sending it" category is today's
semi-humorous name suggestion: "Cajun". It sounds roughly like the
English pronunciation of "caching"Sadly it's not as nicely self-documenting as "opcache".
opcache is fine, its better that it's self describing then exiting.
not:to-be-taken-seriusly
Cause then you don't have to google it to figure out what it is every time,
like T_PAAMAYIM_NEKUDOTAYIM :P
So if you really have to make a name for it, keep it self describing, like: OpsiCache
Other then already being a used name, ops(i) is the word you would say in some
languages when you realize you have done a mistake :)
</not:to-be-taken-seriusly
Hi,
I tried to install the ZendOptimizer+ provided earlier today but wasn't
able to make it work. I compiled it with success but when I looked at the
phpinfo(); I had this :
Opcode Caching Disabled
Optimization Enabled
Startup Failed no value
I'm using the apache2handler (MPM Worker - multi-threaded), PHP Version
5.4.13-dev.
Here's my configure :
'./configure' '--enable-debug' '--enable-bcmath' '--enable-calendar'
'--enable-gd-native-ttf' '--enable-maintainer-zts' '--enable-mbstring'
'--enable-soap' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm'
'--enable-zip' '--with-apxs2=/usr/bin/apxs2'
'--with-config-file-path=/etc/php5/PHP-5.4'
'--with-config-file-scan-dir=/etc/php5/PHP-5.4/conf.d' '--with-curl'
'--with-freetype-dir=/usr/lib' '--with-gd' '--with-jpeg-dir'
'--with-kerberos' '--with-mcrypt'
'--with-mysql-sock=/var/run/mysqld/mysqld.sock' '--with-mysql=mysqlnd'
'--with-mysqli=mysqlnd' '--with-openssl' '--with-pdo-mysql=mysqlnd'
'--with-png-dir' '--with-readline' '--with-xsl' '--with-zlib-dir'
I only added the zend_extension line in my php.ini file.
I tried to look at the log but did not found anything that could explain
why the Startup Failed. I looked a little bit at the code and
the accel_startup worked as expected at the apache start
and ZCG(startup_ok) was equal to 1 at the end of it. I'm suspecting that my
problem is related to the fact that I'm using a multi-threaded environment.
Could it be because the startup_ok variable is in the zend_accel_globals
structure and not in the zend_accel_shared_globals ? And that a
new zend_accel_globals is created for my request where the startup_ok is
not 1 ?
If you have any idea of anything I could have done wrong please let me
know. Also if you need more informations just ask and I'll try to provide
them to you.
Thanks for the help !
Pierrick
For your browsing pleasure:
https://github.com/zend-dev/ZendOptimizerPlus/
An initial README with some instructions is available at
http://bit.ly/VSs5KCWe’ve put it under the PHP license, with the same PHP Group copyright
header as all files in PHP.As per Derick’s idea, we can arrange a webinar for those interested in
better understanding how it works. Note that this will not be a webinar
for the faint of heart – opcode caches are complicated pieces of software;
Attendees should have very good engine-development knowledge to have a good
chance of understanding what’s going on… Stas – your help in that webinar
would be very welcome JZeev
Hi Pierrick,
We didn't use ZTS in Zend commercial products, so it wasn't tested for a
long time.
O+ may definitely have some ZTS related problems.
Please, report an issue at
https://github.com/zend-dev/ZendOptimizerPlus/issues
I'll look into it later
Thanks. Dmitry.
On Thu, Feb 14, 2013 at 1:42 AM, Pierrick Charron pierrick@webstart.frwrote:
Hi,
I tried to install the ZendOptimizer+ provided earlier today but wasn't
able to make it work. I compiled it with success but when I looked at the
phpinfo(); I had this :Opcode Caching Disabled
Optimization Enabled
Startup Failed no valueI'm using the apache2handler (MPM Worker - multi-threaded), PHP Version
5.4.13-dev.Here's my configure :
'./configure' '--enable-debug' '--enable-bcmath' '--enable-calendar'
'--enable-gd-native-ttf' '--enable-maintainer-zts' '--enable-mbstring'
'--enable-soap' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm'
'--enable-zip' '--with-apxs2=/usr/bin/apxs2'
'--with-config-file-path=/etc/php5/PHP-5.4'
'--with-config-file-scan-dir=/etc/php5/PHP-5.4/conf.d' '--with-curl'
'--with-freetype-dir=/usr/lib' '--with-gd' '--with-jpeg-dir'
'--with-kerberos' '--with-mcrypt'
'--with-mysql-sock=/var/run/mysqld/mysqld.sock' '--with-mysql=mysqlnd'
'--with-mysqli=mysqlnd' '--with-openssl' '--with-pdo-mysql=mysqlnd'
'--with-png-dir' '--with-readline' '--with-xsl' '--with-zlib-dir'I only added the zend_extension line in my php.ini file.
I tried to look at the log but did not found anything that could explain
why the Startup Failed. I looked a little bit at the code and
the accel_startup worked as expected at the apache start
and ZCG(startup_ok) was equal to 1 at the end of it. I'm suspecting that my
problem is related to the fact that I'm using a multi-threaded environment.
Could it be because the startup_ok variable is in the zend_accel_globals
structure and not in the zend_accel_shared_globals ? And that a
new zend_accel_globals is created for my request where the startup_ok is
not 1 ?If you have any idea of anything I could have done wrong please let me
know. Also if you need more informations just ask and I'll try to provide
them to you.Thanks for the help !
PierrickFor your browsing pleasure:
https://github.com/zend-dev/ZendOptimizerPlus/
An initial README with some instructions is available at
http://bit.ly/VSs5KCWe’ve put it under the PHP license, with the same PHP Group copyright
header as all files in PHP.As per Derick’s idea, we can arrange a webinar for those interested in
better understanding how it works. Note that this will not be a webinar
for the faint of heart – opcode caches are complicated pieces of
software;
Attendees should have very good engine-development knowledge to have a
good
chance of understanding what’s going on… Stas – your help in that
webinar
would be very welcome JZeev
hi,
For those willing to play with it on Windows, here are the bins for 5.5/VC11
https://twitter.com/PierreJoye/status/301946818835652608
5.3/5.4/5.5 VC9 are coming.
Cheers,
Pierre
@pierrejoye
Zeev Suraski in php.internals (Wed, 13 Feb 2013 16:51:39 +0200):
For your browsing pleasure:
https://github.com/zend-dev/ZendOptimizerPlus/
An initial README with some instructions is available at
http://bit.ly/VSs5KC
Is my impression right that there is still a lot to be done to get this
compiled under Windows? I did not succeed and then looked into
config.m4. There are huge differenced with config.w32,
Jan
It should build ok under Windows - Pierre published binaries even...
Sent from my mobile
Zeev Suraski in php.internals (Wed, 13 Feb 2013 16:51:39 +0200):
For your browsing pleasure:
https://github.com/zend-dev/ZendOptimizerPlus/
An initial README with some instructions is available at
http://bit.ly/VSs5KCIs my impression right that there is still a lot to be done to get this
compiled under Windows? I did not succeed and then looked into
config.m4. There are huge differenced with config.w32,Jan
hi Jan,
Zeev Suraski in php.internals (Wed, 13 Feb 2013 16:51:39 +0200):
For your browsing pleasure:
https://github.com/zend-dev/ZendOptimizerPlus/
An initial README with some instructions is available at
http://bit.ly/VSs5KCIs my impression right that there is still a lot to be done to get this
compiled under Windows? I did not succeed and then looked into
config.m4. There are huge differenced with config.w32,
There are a couple of mistakes in config.w32, Dmitry merged a PR this
morning that should fix them.
In the meantime, I uploaded binaries for all supported PHP versions here:
https://twitter.com/PierreJoye/status/301999105591373824
VC11 builds of PHP 5.5 (php itself :) snapshots are coming shortly too.
Cheers,
Pierre
@pierrejoye
Pierre Joye in php.internals (Thu, 14 Feb 2013 11:21:33 +0100):
Is my impression right that there is still a lot to be done to get this
compiled under Windows? I did not succeed and then looked into
config.m4. There are huge differenced with config.w32,There are a couple of mistakes in config.w32, Dmitry merged a PR this
morning that should fix them.
OK, I will take another shot. It failed with "Don't know how to make
Optimizer\zend_optimizer.c".
In the meantime, I uploaded binaries for all supported PHP versions here:
https://twitter.com/PierreJoye/status/301999105591373824VC11 builds of PHP 5.5 (php itself :) snapshots are coming shortly too.
I also tried to compile it as a normal extension (in PHP 5.4 and PHP
5.5). The standard Windows (VC9) build script tries to make
php_ZendOptimizerPlus.dll in stead of ZendOptimizerPlus.dll. Are there
any tweaks needed in configure.js or something like that to make it part
of the normal build routine?
Jan
hi,
Pierre Joye in php.internals (Thu, 14 Feb 2013 11:21:33 +0100):
Is my impression right that there is still a lot to be done to get this
compiled under Windows? I did not succeed and then looked into
config.m4. There are huge differenced with config.w32,There are a couple of mistakes in config.w32, Dmitry merged a PR this
morning that should fix them.OK, I will take another shot. It failed with "Don't know how to make
Optimizer\zend_optimizer.c".
Yes, this bug is fixed in master, I submitter the PR earlier today.
In the meantime, I uploaded binaries for all supported PHP versions here:
https://twitter.com/PierreJoye/status/301999105591373824VC11 builds of PHP 5.5 (php itself :) snapshots are coming shortly too.
I also tried to compile it as a normal extension (in PHP 5.4 and PHP
5.5). The standard Windows (VC9) build script tries to make
php_ZendOptimizerPlus.dll in stead of ZendOptimizerPlus.dll. Are there
any tweaks needed in configure.js or something like that to make it part
of the normal build routine?
Updating your tree should do it.
--
Pierre
@pierrejoye
Pierre Joye in php.internals (Thu, 14 Feb 2013 12:09:57 +0100):
Yes, this bug is fixed in master, I submitter the PR earlier today.
OK. It builds now.
I also tried to compile it as a normal extension (in PHP 5.4 and PHP
5.5). The standard Windows (VC9) build script tries to make
php_ZendOptimizerPlus.dll in stead of ZendOptimizerPlus.dll. Are there
any tweaks needed in configure.js or something like that to make it part
of the normal build routine?Updating your tree should do it.
It still builds php_ZendOptimizerPlus.dll but that might be because I
added --enable-optimizer-plus=shared to my configure options. I like to
show in my configure line all the extensions I compile in one pass ;-)
I will see what happens if I leave that out.
Anyway, I suppose adding this to my php.ini will work as well:
zend_extension=ext/php_ZendOptimizerPlus.dll
Jan
hi Jan,
I also tried to compile it as a normal extension (in PHP 5.4 and PHP
5.5). The standard Windows (VC9) build script tries to make
php_ZendOptimizerPlus.dll in stead of ZendOptimizerPlus.dll. Are there
any tweaks needed in configure.js or something like that to make it part
of the normal build routine?Updating your tree should do it.
It still builds php_ZendOptimizerPlus.dll but that might be because I
added --enable-optimizer-plus=shared to my configure options. I like to
show in my configure line all the extensions I compile in one pass ;-)
I will see what happens if I leave that out.Anyway, I suppose adding this to my php.ini will work as well:
zend_extension=ext/php_ZendOptimizerPlus.dll
I misread the question, it is expected, like php_xdebug, php_apc, etc.
Cheers,
Pierre
@pierrejoye
Pierre Joye in php.internals (Thu, 14 Feb 2013 12:44:30 +0100):
I misread the question, it is expected, like php_xdebug, php_apc, etc.
Loaded from the command line (PHP 5.5.0alpha4 TS):
This program makes use of the Zend Scripting Language Engine:
Zend Engine v2.5.0-dev, Copyright (c) 1998-2013 Zend Technologies
with Zend Optimizer+ v7.0.0-dev, Copyright (c) 1999-2013, by Zend
Technologies
Time for real tests!
Jan
PS. X64 was a step too far. And php_apc.dll does not compile anymore
under PHP 5.5 after I went back to apc 3.1.13.
Pierre Joye in php.internals (Thu, 14 Feb 2013 11:21:33 +0100):
VC11 builds of PHP 5.5 (php itself :) snapshots are coming shortly too.
I will stick with VC9 for the moment ;-)
http://dl.dropbox.com/u/8954372/php-5.5.0alpha4-Win32-VC9-x86.zip
http://dl.dropbox.com/u/8954372/php-5.5.0alpha4-nts-Win32-VC9-x86.zip
The PHP 5.4.11 and PHP 5.3.21 zips are in my dropbox as well.
Jan
Pierre Joye in php.internals (Thu, 14 Feb 2013 11:21:33 +0100):
VC11 builds of PHP 5.5 (php itself :) snapshots are coming shortly too.
I will stick with VC9 for the moment ;-)
http://dl.dropbox.com/u/8954372/php-5.5.0alpha4-Win32-VC9-x86.zip
http://dl.dropbox.com/u/8954372/php-5.5.0alpha4-nts-Win32-VC9-x86.zipThe PHP 5.4.11 and PHP 5.3.21 zips are in my dropbox as well.
VC9 snaps are already available for all almost all commits at
http://windows.php.net/downloads/snaps/
Releases are at:
http://windows.php.net/qa/ (f.e. a4)
--
Pierre
@pierrejoye
Pierre Joye in php.internals (Thu, 14 Feb 2013 14:47:48 +0100):
VC9 snaps are already available for all almost all commits at
http://windows.php.net/downloads/snaps/
http://windows.php.net/downloads/snaps/php-5.4/r4b900f4/ do not include
php_ZendOptimizerPlus.dll yet.
http://windows.php.net/qa/ (f.e. a4)
http://windows.php.net/downloads/snaps/php-5.5/r1bde2b4/ do not include
php_ZendOptimizerPlus.dll yet.
Or am I looking with my nose?
Jan
hi Jan,
Pierre Joye in php.internals (Thu, 14 Feb 2013 14:47:48 +0100):
VC9 snaps are already available for all almost all commits at
http://windows.php.net/downloads/snaps/http://windows.php.net/downloads/snaps/php-5.4/r4b900f4/ do not include
php_ZendOptimizerPlus.dll yet.http://windows.php.net/qa/ (f.e. a4)
http://windows.php.net/downloads/snaps/php-5.5/r1bde2b4/ do not include
php_ZendOptimizerPlus.dll yet.Or am I looking with my nose?
Yes ;-)
PHP does not bundle Optimizer, at least not yet. Snaps for pecl (or
other external exts) are at:
http://windows.php.net/downloads/pecl/snaps/
And today snaps for Optimizer is at:
http://windows.php.net/downloads/pecl/snaps/Optimizer/7.0.0-dev/
Cheers,
Pierre
@pierrejoye
Pierre Joye in php.internals (Thu, 14 Feb 2013 15:58:21 +0100):
Or am I looking with my nose?
Yes ;-)
Snow for my eyes, frost on my nose. My zips do contain
php_ZendOptimizerPlus.dll and a lot of other extensions.
Jan
Pierre Joye in php.internals (Thu, 14 Feb 2013 15:58:21 +0100):
Or am I looking with my nose?
Yes ;-)
Snow for my eyes, frost on my nose. My zips do contain
php_ZendOptimizerPlus.dll and a lot of other extensions.
That's all nice but we do not do it anymore. Users then tend to think
that these extra extensions are part of the core and/or fully
supported, that's not the case.
Cheers,
Pierre
@pierrejoye