Hi Internals,
as you might have read in the 5.5.0alpha4 announcments, we are moving
forward with 5.5.0. We are already a bit late on the schedule and
we want to begin the beta cycle in 14 days and concentrate on QA
for the 5.5.0 release from now on.
This includes a feature freeze. No new features should be comitted to
the repository once we tagged the first beta on Feb 7. All outstanding
features will have to wait for 5.6.0 in a year unless there is a
really good reason for an exception.
Feature Freeze is on Feb 7, 2013.
Regards,
Julien and David
Hi
2013/1/24 David Soria Parra dsp@php.net:
This includes a feature freeze. No new features should be comitted to
the repository once we tagged the first beta on Feb 7. All outstanding
features will have to wait for 5.6.0 in a year unless there is a
This reminds me of yet another old topic:
http://www.serverphorums.com/read.php?7,374842
and the one before:
http://markmail.org/message/4w6lcbunw3qfof3c
TL;DR, I think it is time to include APC in the core as we so many
times have talked about and most people have agreed, dating back to
the 6.0 meeting in '05 even.
--
regards,
Kalle Sommer Nielsen
kalle@php.net
Hi
2013/1/24 David Soria Parra dsp@php.net:
This includes a feature freeze. No new features should be comitted to
the repository once we tagged the first beta on Feb 7. All outstanding
features will have to wait for 5.6.0 in a year unless there is aThis reminds me of yet another old topic:
http://www.serverphorums.com/read.php?7,374842and the one before:
http://markmail.org/message/4w6lcbunw3qfof3cTL;DR, I think it is time to include APC in the core as we so many
times have talked about and most people have agreed, dating back to
the 6.0 meeting in '05 even.
From what I understood from Rasmus the biggest challenge with merging APC
into core is the fact that the compiler currently isn't built to support
opcode caching. One of the challenges he pointed out was some of the
MAKE_NOP trickery that can make APC's work a bit more complex than
necessary. It's possible to optimize the compiler enough to the point that
APC's code could be reduced down to very simple opcode caching, putting
less stress on the engine and making it easier to maintain.
So far from what I've seen by looking at APC's code is that this problem
isn't trivial to solve without improving the compiler and makes APC's code
a bit bloated. It's also not easy to debug APC either. Judging by the bug
reports on bugs web, many of these bugs are also not trivial to reproduce
let alone debug and fix.
I think that APC should eventually be reduced down to a simple opcode cache
and merged into core, but I also think that Rasmus is right about improving
the compiler to make opcode caching simpler so that APC doesn't have to do
all these tricks.
--
regards,Kalle Sommer Nielsen
kalle@php.net
From what I understood from Rasmus the biggest challenge with merging APC
into core is the fact that the compiler currently isn't built to support
opcode caching. One of the challenges he pointed out was some of the
MAKE_NOP trickery that can make APC's work a bit more complex than
necessary. It's possible to optimize the compiler enough to the point that
APC's code could be reduced down to very simple opcode caching, putting
less stress on the engine and making it easier to maintain.
I think there was some support for moving APC first from pecl to the PHP
standard distribution's ext folder before any tighter integration is
started.
From what I understood from Rasmus the biggest challenge with merging APC
into core is the fact that the compiler currently isn't built to support
opcode caching. One of the challenges he pointed out was some of the
MAKE_NOP trickery that can make APC's work a bit more complex than
necessary. It's possible to optimize the compiler enough to the point that
APC's code could be reduced down to very simple opcode caching, putting
less stress on the engine and making it easier to maintain.I think there was some support for moving APC first from pecl to the PHP
standard distribution's ext folder before any tighter integration is
started.
I'm really not convinced that by moving it to core we will magically get
people to help with it. I have been trying to get people interested for
years, and it hasn't gotten very far. Everyone wants it in the core, but
with a couple of exceptions, nobody is willing to actually work on it to
get it there.
And I can understand the lack of help. It is probably the most
complicated piece of the entire stack. It is a an op_array juggler doing
a complex dance on a tight rope backwards and blindfolded. It is
essentially multi-threaded in that there are multiple processes all
reading and writing the same chunk of memory while dealing with a
compiler that spits out context-sensitive op_arrays that were never
designed to be cached and executed this way.
So the learning curve is steep and the bugs are extremely hard to track
down because it is the only PHP component that isn't a perfect sandbox.
A slight memory corruption almost anywhere in any extension can segfault
a dozen requests later with a backtrace that points to the opcode cache
code. Not to mention web servers like Apache that longjmp() on us at the
wrong time. Zend-signals addresses this, but even in 5.4 they aren't
enabled by default because of stability issues and without those no
shared memory opcode cache is safe.
I firmly believe that we need opcode caching in core. I'm rather
skeptical that simply moving pecl/apc to ext/apc is going to help users
in any way. People have no trouble finding and installing APC today. The
real issue here is robustness and lag time between a PHP release and and
solid APC release and that has to do with resources which are scarce due
to the code complexity. This is the real problem we need to solve.
Either by a number of people stepping up to help with the existing APC
code, or perhaps more realistically making it a priority in PHP 5.6 to
streamline the engine and the executor for opcode caching and either
including a heavily simplified version of APC or writing a new one.
One thing I can guarantee is that if we add it to core in its current
condition it will delay 5.5 by 6+ months if not longer.
-Rasmus
Either by a number of people stepping up to help with the existing APC
code, or perhaps more realistically making it a priority in PHP 5.6 to
streamline the engine and the executor for opcode caching and either
including a heavily simplified version of APC or writing a new one.
Cannot agree more.
One thing I can guarantee is that if we add it to core in its current
condition it will delay 5.5 by 6+ months if not longer.
Same here, I cannot agree more, it exactly matches my thoughts.
Cheers,
Pierre
From what I understood from Rasmus the biggest challenge with merging
APC
into core is the fact that the compiler currently isn't built to support
opcode caching. One of the challenges he pointed out was some of the
MAKE_NOP trickery that can make APC's work a bit more complex than
necessary. It's possible to optimize the compiler enough to the point
that
APC's code could be reduced down to very simple opcode caching, putting
less stress on the engine and making it easier to maintain.I think there was some support for moving APC first from pecl to the PHP
standard distribution's ext folder before any tighter integration is
started.I'm really not convinced that by moving it to core we will magically get
people to help with it. I have been trying to get people interested for
years, and it hasn't gotten very far. Everyone wants it in the core, but
with a couple of exceptions, nobody is willing to actually work on it to
get it there.And I can understand the lack of help. It is probably the most
complicated piece of the entire stack. It is a an op_array juggler doing
a complex dance on a tight rope backwards and blindfolded. It is
essentially multi-threaded in that there are multiple processes all
reading and writing the same chunk of memory while dealing with a
compiler that spits out context-sensitive op_arrays that were never
designed to be cached and executed this way.So the learning curve is steep and the bugs are extremely hard to track
down because it is the only PHP component that isn't a perfect sandbox.
A slight memory corruption almost anywhere in any extension can segfault
a dozen requests later with a backtrace that points to the opcode cache
code. Not to mention web servers like Apache that longjmp() on us at the
wrong time. Zend-signals addresses this, but even in 5.4 they aren't
enabled by default because of stability issues and without those no
shared memory opcode cache is safe.I firmly believe that we need opcode caching in core. I'm rather
skeptical that simply moving pecl/apc to ext/apc is going to help users
in any way. People have no trouble finding and installing APC today. The
real issue here is robustness and lag time between a PHP release and and
solid APC release and that has to do with resources which are scarce due
to the code complexity. This is the real problem we need to solve.
Either by a number of people stepping up to help with the existing APC
code, or perhaps more realistically making it a priority in PHP 5.6 to
streamline the engine and the executor for opcode caching and either
including a heavily simplified version of APC or writing a new one.
That feels like a safe idea. I'm convinced that having more internals
documentation will help
developpers understand at least the engine (that's what interest us here).
I know it's a hard task, but we all here have blogs where sometimes we
write great articles
about a part of internals, I think we should focus on working alltogether
writing a real technical doc for the engine,
that will help people (like me for example), understand some dark parts of
it, and then find ideas or solutions for it to
evolve the right way.
One thing I can guarantee is that if we add it to core in its current
condition it will delay 5.5 by 6+ months if not longer.
Ok that seems clear.
Julien.Pauli
And I can understand the lack of help. It is probably the most
complicated piece of the entire stack. It is a an op_array juggler doing
a complex dance on a tight rope backwards and blindfolded. It is
essentially multi-threaded in that there are multiple processes all
reading and writing the same chunk of memory while dealing with a
compiler that spits out context-sensitive op_arrays that were never
designed to be cached and executed this way.
I'm not sure if anyone has a deep understanding of APC and the problems
the existing compiler design causes for it, perhaps another great place
to start on this project is to get a list of the high-level problems the
compiler does or doesn't do that could be changed. Then we can break
those down and identify the parts of the engine that will require some
re-work.
I firmly believe that we need opcode caching in core. I'm rather
skeptical that simply moving pecl/apc to ext/apc is going to help users
in any way. People have no trouble finding and installing APC today. The
real issue here is robustness and lag time between a PHP release and and
solid APC release and that has to do with resources which are scarce due
to the code complexity. This is the real problem we need to solve.
Either by a number of people stepping up to help with the existing APC
code, or perhaps more realistically making it a priority in PHP 5.6 to
streamline the engine and the executor for opcode caching and either
including a heavily simplified version of APC or writing a new one.That feels like a safe idea. I'm convinced that having more internals
documentation will help
developpers understand at least the engine (that's what interest us here).
I agree that bringing some more documentation can only help; people with
less experience or who have missing areas of expertise in the core will
more easily be able to step up and help with the problem.
I know it's a hard task, but we all here have blogs where sometimes we
write great articles
about a part of internals, I think we should focus on working alltogether
writing a real technical doc for the engine,
that will help people (like me for example), understand some dark parts of
it, and then find ideas or solutions for it to
evolve the right way.
This may only be my perception, but in having to learn what I did for
the failed accessors project I felt like there were 2 or 3 more or less
identical ways the compiler and/or executor was doing the same thing.
Without further understanding I presumed it was because as time went by
a new "way" was added because the old way just wasn't enough. In
essence adding to the technical debt. Possibly/probably just a
misconception of my own but that's the way it felt.
I'd be happy to jump in and help fix this in any way I can but I don't
even know where the string starts or what it looks like to unravel the
problem at this point.
--
-Clint
One thing I can guarantee is that if we add it to core in its current
condition it will delay 5.5 by 6+ months if not longer.
I think it is fine if APC doesn't support all features of PHP. When
there is a clear documentation, everybody can decide if he skips some
features for better performance. Maybe this also offers room for more
optimizations.
Regards,
Thomas
From what I understood from Rasmus the biggest challenge with merging APC
into core is the fact that the compiler currently isn't built to support
opcode caching. One of the challenges he pointed out was some of the
MAKE_NOP trickery that can make APC's work a bit more complex than
necessary. It's possible to optimize the compiler enough to the point that
APC's code could be reduced down to very simple opcode caching, putting
less stress on the engine and making it easier to maintain.I think there was some support for moving APC first from pecl to the PHP
standard distribution's ext folder before any tighter integration is
started.I'm really not convinced that by moving it to core we will magically get
people to help with it. I have been trying to get people interested for
years, and it hasn't gotten very far. Everyone wants it in the core, but
with a couple of exceptions, nobody is willing to actually work on it to
get it there.And I can understand the lack of help. It is probably the most
complicated piece of the entire stack. It is a an op_array juggler doing
a complex dance on a tight rope backwards and blindfolded. It is
essentially multi-threaded in that there are multiple processes all
reading and writing the same chunk of memory while dealing with a
compiler that spits out context-sensitive op_arrays that were never
designed to be cached and executed this way.So the learning curve is steep and the bugs are extremely hard to track
down because it is the only PHP component that isn't a perfect sandbox.
A slight memory corruption almost anywhere in any extension can segfault
a dozen requests later with a backtrace that points to the opcode cache
code. Not to mention web servers like Apache that longjmp() on us at the
wrong time. Zend-signals addresses this, but even in 5.4 they aren't
enabled by default because of stability issues and without those no
shared memory opcode cache is safe.I firmly believe that we need opcode caching in core. I'm rather
skeptical that simply moving pecl/apc to ext/apc is going to help users
in any way. People have no trouble finding and installing APC today. The
real issue here is robustness and lag time between a PHP release and and
solid APC release and that has to do with resources which are scarce due
to the code complexity. This is the real problem we need to solve.
Either by a number of people stepping up to help with the existing APC
code, or perhaps more realistically making it a priority in PHP 5.6 to
streamline the engine and the executor for opcode caching and either
including a heavily simplified version of APC or writing a new one.One thing I can guarantee is that if we add it to core in its current
condition it will delay 5.5 by 6+ months if not longer.-Rasmus
2013/1/25 Thomas Bley thbley+php@gmail.com
One thing I can guarantee is that if we add it to core in its current
condition it will delay 5.5 by 6+ months if not longer.I think it is fine if APC doesn't support all features of PHP. When
there is a clear documentation, everybody can decide if he skips some
features for better performance. Maybe this also offers room for more
optimizations.
You cannot simply decide, what features you want to use, when you rely on
third-party-libraries from time to time.
Regards,
ThomasOn Fri, Jan 25, 2013 at 9:19 AM, Rasmus Lerdorf rasmus@lerdorf.com
wrote:From what I understood from Rasmus the biggest challenge with merging
APC
into core is the fact that the compiler currently isn't built to
support
opcode caching. One of the challenges he pointed out was some of the
MAKE_NOP trickery that can make APC's work a bit more complex than
necessary. It's possible to optimize the compiler enough to the point
that
APC's code could be reduced down to very simple opcode caching, putting
less stress on the engine and making it easier to maintain.I think there was some support for moving APC first from pecl to the PHP
standard distribution's ext folder before any tighter integration is
started.I'm really not convinced that by moving it to core we will magically get
people to help with it. I have been trying to get people interested for
years, and it hasn't gotten very far. Everyone wants it in the core, but
with a couple of exceptions, nobody is willing to actually work on it to
get it there.And I can understand the lack of help. It is probably the most
complicated piece of the entire stack. It is a an op_array juggler doing
a complex dance on a tight rope backwards and blindfolded. It is
essentially multi-threaded in that there are multiple processes all
reading and writing the same chunk of memory while dealing with a
compiler that spits out context-sensitive op_arrays that were never
designed to be cached and executed this way.So the learning curve is steep and the bugs are extremely hard to track
down because it is the only PHP component that isn't a perfect sandbox.
A slight memory corruption almost anywhere in any extension can segfault
a dozen requests later with a backtrace that points to the opcode cache
code. Not to mention web servers like Apache that longjmp() on us at the
wrong time. Zend-signals addresses this, but even in 5.4 they aren't
enabled by default because of stability issues and without those no
shared memory opcode cache is safe.I firmly believe that we need opcode caching in core. I'm rather
skeptical that simply moving pecl/apc to ext/apc is going to help users
in any way. People have no trouble finding and installing APC today. The
real issue here is robustness and lag time between a PHP release and and
solid APC release and that has to do with resources which are scarce due
to the code complexity. This is the real problem we need to solve.
Either by a number of people stepping up to help with the existing APC
code, or perhaps more realistically making it a priority in PHP 5.6 to
streamline the engine and the executor for opcode caching and either
including a heavily simplified version of APC or writing a new one.One thing I can guarantee is that if we add it to core in its current
condition it will delay 5.5 by 6+ months if not longer.-Rasmus
--
--
You cannot simply decide
if you cannot decide, you can run tests or turn it off. Having it off
by default would be the same as today.
Most people activate apc without further thinking.
Regards,
Thomas
2013/1/25 Thomas Bley thbley+php@gmail.com
One thing I can guarantee is that if we add it to core in its current
condition it will delay 5.5 by 6+ months if not longer.I think it is fine if APC doesn't support all features of PHP. When
there is a clear documentation, everybody can decide if he skips some
features for better performance. Maybe this also offers room for more
optimizations.You cannot simply decide, what features you want to use, when you rely on
third-party-libraries from time to time.Regards,
ThomasOn Fri, Jan 25, 2013 at 9:19 AM, Rasmus Lerdorf rasmus@lerdorf.com
wrote:From what I understood from Rasmus the biggest challenge with merging
APC
into core is the fact that the compiler currently isn't built to
support
opcode caching. One of the challenges he pointed out was some of the
MAKE_NOP trickery that can make APC's work a bit more complex than
necessary. It's possible to optimize the compiler enough to the point
that
APC's code could be reduced down to very simple opcode caching,
putting
less stress on the engine and making it easier to maintain.I think there was some support for moving APC first from pecl to the
PHP
standard distribution's ext folder before any tighter integration is
started.I'm really not convinced that by moving it to core we will magically get
people to help with it. I have been trying to get people interested for
years, and it hasn't gotten very far. Everyone wants it in the core, but
with a couple of exceptions, nobody is willing to actually work on it to
get it there.And I can understand the lack of help. It is probably the most
complicated piece of the entire stack. It is a an op_array juggler doing
a complex dance on a tight rope backwards and blindfolded. It is
essentially multi-threaded in that there are multiple processes all
reading and writing the same chunk of memory while dealing with a
compiler that spits out context-sensitive op_arrays that were never
designed to be cached and executed this way.So the learning curve is steep and the bugs are extremely hard to track
down because it is the only PHP component that isn't a perfect sandbox.
A slight memory corruption almost anywhere in any extension can segfault
a dozen requests later with a backtrace that points to the opcode cache
code. Not to mention web servers like Apache that longjmp() on us at the
wrong time. Zend-signals addresses this, but even in 5.4 they aren't
enabled by default because of stability issues and without those no
shared memory opcode cache is safe.I firmly believe that we need opcode caching in core. I'm rather
skeptical that simply moving pecl/apc to ext/apc is going to help users
in any way. People have no trouble finding and installing APC today. The
real issue here is robustness and lag time between a PHP release and and
solid APC release and that has to do with resources which are scarce due
to the code complexity. This is the real problem we need to solve.
Either by a number of people stepping up to help with the existing APC
code, or perhaps more realistically making it a priority in PHP 5.6 to
streamline the engine and the executor for opcode caching and either
including a heavily simplified version of APC or writing a new one.One thing I can guarantee is that if we add it to core in its current
condition it will delay 5.5 by 6+ months if not longer.-Rasmus
--
--
One thing I can guarantee is that if we add it to core in its current
condition it will delay 5.5 by 6+ months if not longer.
I am not familiar with the details of opcodes at all, let alone APC.
However, I think it would be wise to delay major core changes for APC
until the next major version of PHP. I don't think a minor release is
appropriate for this kind of change because of the amount of possible
breakage.
This is just my opinion, of course.
Either by a number of people stepping up to help with the existing APC
code, or
perhaps more realistically making it a priority in PHP 5.6 to streamline
the
engine and the executor for opcode caching and either including a
heavily
simplified version of APC or writing a new one.One thing I can guarantee is that if we add it to core in its current
condition it
will delay 5.5 by 6+ months if not longer.
There's another option. We have the Optimizer+ component which is
current, a bit faster than APC, worked with PHP 5.4 from the get go and
already fully supports 5.5 - and now that it's been free for use for
several years, we'd actually be happy to opensource it and make it a part
of core. An extra benefit would be that we'd commit to maintain it,
although of course, community contribution will be very welcome.
Here too, it's code with a very long history, some of which even predates
PHP 4.0. But It Works(tm), and we could put some effort into cleaning it
up and beautifying it.
I think we can actually do it on time for 5.5.0, or with a relatively
minor delay that might be worth it. I'm sure most users would prefer the
version to take a bit longer if it comes with an opcode cache right off
the bat.
There'll most probably be APIs we'd want to merge from APC, but doing that
should be easy - and we can get the good of both worlds.
Zeev
Either by a number of people stepping up to help with the existing APC
code, or
perhaps more realistically making it a priority in PHP 5.6 to streamline
the
engine and the executor for opcode caching and either including a
heavily
simplified version of APC or writing a new one.One thing I can guarantee is that if we add it to core in its current
condition it
will delay 5.5 by 6+ months if not longer.There's another option. We have the Optimizer+ component which is
current, a bit faster than APC, worked with PHP 5.4 from the get go and
already fully supports 5.5 - and now that it's been free for use for
several years, we'd actually be happy to opensource it and make it a part
of core. An extra benefit would be that we'd commit to maintain it,
although of course, community contribution will be very welcome.
Here too, it's code with a very long history, some of which even predates
PHP 4.0. But It Works(tm), and we could put some effort into cleaning it
up and beautifying it.
I like the idea. If this was implemented in core, and the need for APC opcode caching disappeared, would APC still be actively maintained for userland functions (e.g. apc_store, apc_*)?
I think we can actually do it on time for 5.5.0, or with a relatively
minor delay that might be worth it. I'm sure most users would prefer the
version to take a bit longer if it comes with an opcode cache right off
the bat.
There'll most probably be APIs we'd want to merge from APC, but doing that
should be easy - and we can get the good of both worlds.Zeev
Either by a number of people stepping up to help with the existing APC
code, or
perhaps more realistically making it a priority in PHP 5.6 to streamline
the
engine and the executor for opcode caching and either including a
heavily
simplified version of APC or writing a new one.One thing I can guarantee is that if we add it to core in its current
condition it
will delay 5.5 by 6+ months if not longer.There's another option. We have the Optimizer+ component which is
current, a bit faster than APC, worked with PHP 5.4 from the get go and
already fully supports 5.5 - and now that it's been free for use for
several years, we'd actually be happy to opensource it and make it a part
of core. An extra benefit would be that we'd commit to maintain it,
although of course, community contribution will be very welcome.
Here too, it's code with a very long history, some of which even predates
PHP 4.0. But It Works(tm), and we could put some effort into cleaning it
up and beautifying it.I like the idea. If this was implemented in core, and the need for APC
opcode caching disappeared, would APC still be actively maintained for
userland functions (e.g. apc_store, apc_*)?
Well, the APC idea was anyway to merge an Opcode cache to Core, and only an
Opcode cache (correct if I'm wrong).
apc_store() etc... are userland shared memory function, and should be
migrated into another extensions, on which we could then allocate devs to
work on, new ideas, etc...
Julien.Pauli
Either by a number of people stepping up to help with the existing APC
code, or
perhaps more realistically making it a priority in PHP 5.6 to streamline
the
engine and the executor for opcode caching and either including a
heavily
simplified version of APC or writing a new one.One thing I can guarantee is that if we add it to core in its current
condition it
will delay 5.5 by 6+ months if not longer.There's another option. We have the Optimizer+ component which is
current, a bit faster than APC, worked with PHP 5.4 from the get go and
already fully supports 5.5 - and now that it's been free for use for
several years, we'd actually be happy to opensource it and make it a part
of core. An extra benefit would be that we'd commit to maintain it,
although of course, community contribution will be very welcome.
Here too, it's code with a very long history, some of which even predates
PHP 4.0. But It Works(tm), and we could put some effort into cleaning it
up and beautifying it.I like the idea. If this was implemented in core, and the need for APC opcode caching disappeared, would APC still be actively maintained for userland functions (e.g. apc_store, apc_*)?
Well, the APC idea was anyway to merge an Opcode cache to Core, and only an Opcode cache (correct if I'm wrong).
apc_store() etc... are userland shared memory function, and should be migrated into another extensions, on which we could then allocate devs to work on, new ideas, etc…
No, you're right. With Optimizer+ showing a slightly better performance than APC, being "privately" and publicly maintained, open-sourced, already compatible up to 5.5, I see it as a great candidate for core integration. I'd still like to keep APC as a separate extension, but packaged with PHP, for data-only caching.
@Zeev, is anyone writing up an RFC for this?
Julien.Pauli
@Zeev, is anyone writing up an RFC for this?
Not yet, I'll write one.
Zeev
-----Original Message-----
From: Will Fitch [mailto:wfitch@meetme.com] On Behalf Of Will Fitch
Sent: Friday, January 25, 2013 6:48 PM
To: Zeev Suraski; Rasmus Lerdorf
Cc: Ralf Lang; internals@lists.php.net
Subject: Re: [PHP-DEV] HEADS UP: Upcoming Feature Freeze for PHP 5.5.0Either by a number of people stepping up to help with the existing
APC
code, or
perhaps more realistically making it a priority in PHP 5.6 to
streamline
the
engine and the executor for opcode caching and either including a
heavily
simplified version of APC or writing a new one.One thing I can guarantee is that if we add it to core in its current
condition it
will delay 5.5 by 6+ months if not longer.There's another option. We have the Optimizer+ component which is
current, a bit faster than APC, worked with PHP 5.4 from the get go
and already fully supports 5.5 - and now that it's been free for use
for several years, we'd actually be happy to opensource it and make it
a part of core. An extra benefit would be that we'd commit to
maintain it, although of course, community contribution will be very
welcome.
Here too, it's code with a very long history, some of which even
predates PHP 4.0. But It Works(tm), and we could put some effort into
cleaning it up and beautifying it.I like the idea. If this was implemented in core, and the need for APC
opcode
caching disappeared, would APC still be actively maintained for userland
functions (e.g. apc_store, apc_*)?
We could either do that, or create some sort of a merge between the two
projects and take the apc_*() APIs into a combined module. I think that
would give us the best of both worlds.
Zeev
There's another option. We have the Optimizer+ component which is
current, a bit faster than APC, worked with PHP 5.4 from the get go and
already fully supports 5.5 - and now that it's been free for use for
several years, we'd actually be happy to opensource it and make it a part
of core. An extra benefit would be that we'd commit to maintain it,
although of course, community contribution will be very welcome.
Here too, it's code with a very long history, some of which even predates
PHP 4.0. But It Works(tm), and we could put some effort into cleaning it
up and beautifying it.
I think we can actually do it on time for 5.5.0, or with a relatively
minor delay that might be worth it. I'm sure most users would prefer the
version to take a bit longer if it comes with an opcode cache right off
the bat.
There'll most probably be APIs we'd want to merge from APC, but doing that
should be easy - and we can get the good of both worlds.
I would be ok with that. The goal here is opcode cacheing in core. How
we get there is less important. The one thing we can do bringing an old
codebase into core is to clean it up quite a bit since we'd know the
target version. All the ifdefs for older versions can go away, and some
of the tricks that need to be done could be shuffled into the
compiler/executor to streamline things.
I am also not worried about userspace compatibility for things like
apc_store/fetch. Any software written to make use of that already has
conditional checks around it plus that feature needs a serious re-think
anyway. Sharing a lock with op_array handling really doesn't scale.
-Rasmus
Any software written to make use of that already has
conditional checks around it plus that feature needs a serious re-think
anyway.
FWIW, we only deploy with APC, so we don't necessarily have checks guarding apc_fetch()/apc_store().
That said, it would be trivial to write wrapper functions that call a different API if they were compatible in any way.
S
-----Original Message-----
From: Rasmus Lerdorf [mailto:rasmus@lerdorf.com]
Sent: Friday, January 25, 2013 7:16 PM
To: Zeev Suraski
Cc: Ralf Lang; internals@lists.php.net
Subject: Re: [PHP-DEV] HEADS UP: Upcoming Feature Freeze for PHP 5.5.0There's another option. We have the Optimizer+ component which is
current, a bit faster than APC, worked with PHP 5.4 from the get go
and already fully supports 5.5 - and now that it's been free for use
for several years, we'd actually be happy to opensource it and make it
a part of core. An extra benefit would be that we'd commit to
maintain it, although of course, community contribution will be very
welcome.
Here too, it's code with a very long history, some of which even
predates PHP 4.0. But It Works(tm), and we could put some effort into
cleaning it up and beautifying it.
I think we can actually do it on time for 5.5.0, or with a relatively
minor delay that might be worth it. I'm sure most users would prefer
the version to take a bit longer if it comes with an opcode cache
right off the bat.
There'll most probably be APIs we'd want to merge from APC, but doing
that should be easy - and we can get the good of both worlds.I would be ok with that. The goal here is opcode cacheing in core. How we
get
there is less important. The one thing we can do bringing an old codebase
into
core is to clean it up quite a bit since we'd know the target version. All
the ifdefs
for older versions can go away, and some of the tricks that need to be
done
could be shuffled into the compiler/executor to streamline things.
I agree. It would probably make sense to only maintain it for 5.5.0, or
perhaps both 5.4.0 and 5.5.0 since those will be the two supported versions
for years to come. No real point in supporting 5.3 and earlier, and I bet
we can clean things quite a bit with such an assumption. Tighter
integration may also prove helpful.
I am also not worried about userspace compatibility for things like
apc_store/fetch. Any software written to make use of that already has
conditional checks around it plus that feature needs a serious re-think
anyway.
Sharing a lock with op_array handling really doesn't scale.
Ideally I think we'll want to have some sort of continuity, so we could
either keep APC available as a data-cache-only extension (either in core or
outside), or merge this code together with Optimizer+. One other thing we
may consider is our data caching component, which is already decoupled from
Optimizer+, and exposes APC-compatible APIs - we can look into opensourcing
it as well (it's already free today).
Zeev
hi Zeev,
Either by a number of people stepping up to help with the existing APC
code, or
perhaps more realistically making it a priority in PHP 5.6 to streamline
the
engine and the executor for opcode caching and either including a
heavily
simplified version of APC or writing a new one.One thing I can guarantee is that if we add it to core in its current
condition it
will delay 5.5 by 6+ months if not longer.There's another option. We have the Optimizer+ component which is
current, a bit faster than APC, worked with PHP 5.4 from the get go and
already fully supports 5.5 - and now that it's been free for use for
several years, we'd actually be happy to opensource it and make it a part
of core. An extra benefit would be that we'd commit to maintain it,
although of course, community contribution will be very welcome.
Here too, it's code with a very long history, some of which even predates
PHP 4.0. But It Works(tm), and we could put some effort into cleaning it
up and beautifying it.
Thanks, That sounds great.
I think we can actually do it on time for 5.5.0, or with a relatively
minor delay that might be worth it. I'm sure most users would prefer the
version to take a bit longer if it comes with an opcode cache right off
the bat.
There'll most probably be APIs we'd want to merge from APC, but doing that
should be easy - and we can get the good of both worlds.
Please don't bring over the user cache, please don't :-)
Quesiton: Does it support both NTS and TS?
Cheers,
Pierre
@pierrejoye
-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Friday, January 25, 2013 8:42 PM
To: Zeev Suraski
Cc: Rasmus Lerdorf; Ralf Lang; PHP internals
Subject: Re: [PHP-DEV] HEADS UP: Upcoming Feature Freeze for PHP 5.5.0hi Zeev,
Either by a number of people stepping up to help with the existing
APC
code, or
perhaps more realistically making it a priority in PHP 5.6 to
streamline
the
engine and the executor for opcode caching and either including a
heavily
simplified version of APC or writing a new one.One thing I can guarantee is that if we add it to core in its current
condition it
will delay 5.5 by 6+ months if not longer.There's another option. We have the Optimizer+ component which is
current, a bit faster than APC, worked with PHP 5.4 from the get go
and already fully supports 5.5 - and now that it's been free for use
for several years, we'd actually be happy to opensource it and make it
a part of core. An extra benefit would be that we'd commit to
maintain it, although of course, community contribution will be very
welcome.
Here too, it's code with a very long history, some of which even
predates PHP 4.0. But It Works(tm), and we could put some effort into
cleaning it up and beautifying it.Thanks, That sounds great.
I think we can actually do it on time for 5.5.0, or with a relatively
minor delay that might be worth it. I'm sure most users would prefer
the version to take a bit longer if it comes with an opcode cache
right off the bat.
There'll most probably be APIs we'd want to merge from APC, but doing
that should be easy - and we can get the good of both worlds.Please don't bring over the user cache, please don't :-)
Sounds like there's concensus we don't want these things coupled, so we
should probably handle that part separately :)
Quesiton: Does it support both NTS and TS?
I think it used to but if it did that part hasn't been maintained for a
very long time. Not sure where it stands right now...
Zeev
-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Friday, January 25, 2013 8:42 PM
To: Zeev Suraski
Cc: Rasmus Lerdorf; Ralf Lang; PHP internals
Subject: Re: [PHP-DEV] HEADS UP: Upcoming Feature Freeze for PHP 5.5.0hi Zeev,
Either by a number of people stepping up to help with the existing
APC
code, or
perhaps more realistically making it a priority in PHP 5.6 to
streamline
the
engine and the executor for opcode caching and either including a
heavily
simplified version of APC or writing a new one.One thing I can guarantee is that if we add it to core in its current
condition it
will delay 5.5 by 6+ months if not longer.There's another option. We have the Optimizer+ component which is
current, a bit faster than APC, worked with PHP 5.4 from the get go
and already fully supports 5.5 - and now that it's been free for use
for several years, we'd actually be happy to opensource it and make it
a part of core. An extra benefit would be that we'd commit to
maintain it, although of course, community contribution will be very
welcome.
Here too, it's code with a very long history, some of which even
predates PHP 4.0. But It Works(tm), and we could put some effort into
cleaning it up and beautifying it.Thanks, That sounds great.
I think we can actually do it on time for 5.5.0, or with a relatively
minor delay that might be worth it. I'm sure most users would prefer
the version to take a bit longer if it comes with an opcode cache
right off the bat.
There'll most probably be APIs we'd want to merge from APC, but doing
that should be easy - and we can get the good of both worlds.Please don't bring over the user cache, please don't :-)
Sounds like there's concensus we don't want these things coupled, so we
should probably handle that part separately :)Quesiton: Does it support both NTS and TS?
I think it used to but if it did that part hasn't been maintained for a
very long time. Not sure where it stands right now...
That's where APC is very stable, we have spent quite some time to make
it TS-ready, windows and linux. That's an area where I can help.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hi!
There's another option. We have the Optimizer+ component which is
current, a bit faster than APC, worked with PHP 5.4 from the get go and
already fully supports 5.5 - and now that it's been free for use for
several years, we'd actually be happy to opensource it and make it a part
of core. An extra benefit would be that we'd commit to maintain it,
That would be excellent! I probably also could be of some help here, if
its needed, since I'm familiar with the codebase (while my knowledge of
the APC code is minimal).
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
-----Original Message-----
From: Stas Malyshev [mailto:smalyshev@sugarcrm.com]
Sent: Friday, January 25, 2013 8:45 PM
To: Zeev Suraski
Cc: Rasmus Lerdorf; Ralf Lang; internals@lists.php.net
Subject: Re: [PHP-DEV] HEADS UP: Upcoming Feature Freeze for PHP 5.5.0Hi!
There's another option. We have the Optimizer+ component which is
current, a bit faster than APC, worked with PHP 5.4 from the get go
and already fully supports 5.5 - and now that it's been free for use
for several years, we'd actually be happy to opensource it and make it
a part of core. An extra benefit would be that we'd commit to
maintain it,That would be excellent! I probably also could be of some help here, if
its
needed, since I'm familiar with the codebase (while my knowledge of the
APC
code is minimal).
That would be awesome!
Ok, I'll write up an RFC, and in parallel we'll try to figure out the
mechanics of actually making it happen.
Zeev
Ok, I'll write up an RFC, and in parallel we'll try to figure out the
mechanics of actually making it happen.
Commit to master maybe and we can work on cleaning it up for the 5.5 branch.
-Rasmus
Ok, I'll write up an RFC, and in parallel we'll try to figure out the
mechanics of actually making it happen.Commit to master maybe and we can work on cleaning it up for the 5.5 branch.
I would prefer to have it in pecl and merge once ready/cleaned up.
Yes, same idea than with APC, except that it could be faster (for what
I read, waiting to see the sources). Also we can review and do the
changes more easily.
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
On Fri, Jan 25, 2013 at 7:53 PM, Rasmus Lerdorf rasmus@lerdorf.com
wrote:Ok, I'll write up an RFC, and in parallel we'll try to figure out the
mechanics of actually making it happen.Commit to master maybe and we can work on cleaning it up for the 5.5
branch.I would prefer to have it in pecl and merge once ready/cleaned up.
Yes, same idea than with APC, except that it could be faster (for what
I read, waiting to see the sources). Also we can review and do the
changes more easily.--
Pierre@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
I think I can help on things as well.
I'm really looking forward in seeing the source code.
I guess it will be PHP licenced right ?
Julien.Pauli
Pierre et al,
I would prefer to have it in pecl and merge once ready/cleaned up.
Yes, same idea than with APC, except that it could be faster (for what
I read, waiting to see the sources). Also we can review and do the
changes more easily.
Well, I think the one issue with doing it in PECL first is that it prevents
some deeper engine integration that could benefit the implementation
significantly.
With that said, I think it's a bit too tight to try to merge this in for
the 5.5 beta freeze. Given the current RFC process requires a minimum of 2
weeks (1 of comments and 1 of voting), it feels tight. I'm not saying that
I think we should stick to the numbers hard in this particular case, but
it's also not a trivial patch, and I feel that rushing wouldn't be the
best idea.
So with that said, may I suggest that we add 1 more round of Alpha to the
5.5 release cycle, with the specific intent of merging this in (assuming
the implementation goes well). So we'd be talking about adding
approximately 2 weeks to the cycle, but it would ease the time and
implementation pressures that could otherwise cause issues. I think this
feature is worth pushing 5.5 back slightly, but at the same time not
delaying it indefinitely until this gets in. So if in 4 weeks (the time
until the beta, under this strategy) this isn't ready, it wouldn't make
5.5. But at the same time it gives us enough time to implement it,
understand the implementation and make a decision that's based on a
concrete implementation than an "in-progress" one.
Thoughts?
Anthony
On Sat, Jan 26, 2013 at 9:26 AM, Anthony Ferrara ircmaxell@gmail.comwrote:
Pierre et al,
I would prefer to have it in pecl and merge once ready/cleaned up.
Yes, same idea than with APC, except that it could be faster (for what
I read, waiting to see the sources). Also we can review and do the
changes more easily.Well, I think the one issue with doing it in PECL first is that it prevents
some deeper engine integration that could benefit the implementation
significantly.With that said, I think it's a bit too tight to try to merge this in for
the 5.5 beta freeze. Given the current RFC process requires a minimum of 2
weeks (1 of comments and 1 of voting), it feels tight. I'm not saying that
I think we should stick to the numbers hard in this particular case, but
it's also not a trivial patch, and I feel that rushing wouldn't be the
best idea.So with that said, may I suggest that we add 1 more round of Alpha to the
5.5 release cycle, with the specific intent of merging this in (assuming
the implementation goes well). So we'd be talking about adding
approximately 2 weeks to the cycle, but it would ease the time and
implementation pressures that could otherwise cause issues. I think this
feature is worth pushing 5.5 back slightly, but at the same time not
delaying it indefinitely until this gets in. So if in 4 weeks (the time
until the beta, under this strategy) this isn't ready, it wouldn't make
5.5. But at the same time it gives us enough time to implement it,
understand the implementation and make a decision that's based on a
concrete implementation than an "in-progress" one.Thoughts?
I'm ok with that, that's safe and clean :)
Julien.P
hi Anthony,
Pierre et al,
I would prefer to have it in pecl and merge once ready/cleaned up.
Yes, same idea than with APC, except that it could be faster (for what
I read, waiting to see the sources). Also we can review and do the
changes more easily.Well, I think the one issue with doing it in PECL first is that it prevents
some deeper engine integration that could benefit the implementation
significantly.With that said, I think it's a bit too tight to try to merge this in for the
5.5 beta freeze. Given the current RFC process requires a minimum of 2 weeks
(1 of comments and 1 of voting), it feels tight. I'm not saying that I think
we should stick to the numbers hard in this particular case, but it's also
not a trivial patch, and I feel that rushing wouldn't be the best idea.So with that said, may I suggest that we add 1 more round of Alpha to the
5.5 release cycle, with the specific intent of merging this in (assuming the
implementation goes well). So we'd be talking about adding approximately 2
weeks to the cycle, but it would ease the time and implementation pressures
that could otherwise cause issues. I think this feature is worth pushing 5.5
back slightly, but at the same time not delaying it indefinitely until this
gets in. So if in 4 weeks (the time until the beta, under this strategy)
this isn't ready, it wouldn't make 5.5. But at the same time it gives us
enough time to implement it, understand the implementation and make a
decision that's based on a concrete implementation than an "in-progress"
one.Thoughts?
It sounds good to me.
However I would still like to have it in pecl so we can improve for
php 5.3/4 as well. Or we will have to duplicate the efforts between
APC and optimizer for the next years.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
…or perhaps more realistically making it a priority in PHP 5.6 to
streamline the engine and the executor for opcode caching and either
including a heavily simplified version of APC or writing a new one.
I think that's probably one of the key points to take away here. Making
things less complex for an opcode cache also benefits other tools.
(Either with APC, or if we choose to pick Optimizer+)
cheers,
Derick
Hello,
I'm not sure if it could be considered as a feature but what about these
RFCs:
https://wiki.php.net/rfc/error-optimizations
https://wiki.php.net/rfc/grisu3-strtod
Some of them have been opened for some time now.
Also, wouldn't a cleanup of the current RFC listed for PHP help out in the
process? I'm not sure what's the process for this, but it should be done at
some point imho.
Best regards.
Florin Patan
https://github.com/dlsniper
Hi Internals,
as you might have read in the 5.5.0alpha4 announcments, we are moving
forward with 5.5.0. We are already a bit late on the schedule and
we want to begin the beta cycle in 14 days and concentrate on QA
for the 5.5.0 release from now on.This includes a feature freeze. No new features should be comitted to
the repository once we tagged the first beta on Feb 7. All outstanding
features will have to wait for 5.6.0 in a year unless there is a
really good reason for an exception.Feature Freeze is on Feb 7, 2013.
Regards,
Julien and David