Greetings
As the process for trunk grows, I think we should consider which
extensions we will move in and out of the core, this thread however is
solely about moving APC into the core.
As original proposed and agreed on the PDM in Paris, was to include
APC in PHP6, and not turn it on by default. I think it will benefit
both us and the community if we move APC into the core (trunk, 5.4).
APC is one of the most popular extensions at PECL and many core devs
also work on APC.
Currently the only issue I see by putting APC into the core is the CS,
as APC uses spaces instead of tabs.
Another thing we might want to look at is whether we should support
5.2, or simply upgrade APC's version and break backwards compatibility
so we don't have a layer of checks for macros that wasn't available in
previous version, perhaps only require 5.3+ within the APC code, this
however is not really a question of including APC in the core, but
rather a per extension discussion ;-)
What are your views on including APC in the core, or reasons not to?
--
regards,
Kalle Sommer Nielsen
kalle@php.net
I for one think it is a really good idea, there is no compelling
reason not to include APC, I would even go as far as say we should
enable it by default.
+1
Greetings
As the process for trunk grows, I think we should consider which
extensions we will move in and out of the core, this thread however is
solely about moving APC into the core.As original proposed and agreed on the PDM in Paris, was to include
APC in PHP6, and not turn it on by default. I think it will benefit
both us and the community if we move APC into the core (trunk, 5.4).
APC is one of the most popular extensions at PECL and many core devs
also work on APC.Currently the only issue I see by putting APC into the core is the CS,
as APC uses spaces instead of tabs.Another thing we might want to look at is whether we should support
5.2, or simply upgrade APC's version and break backwards compatibility
so we don't have a layer of checks for macros that wasn't available in
previous version, perhaps only require 5.3+ within the APC code, this
however is not really a question of including APC in the core, but
rather a per extension discussion ;-)What are your views on including APC in the core, or reasons not to?
--
regards,Kalle Sommer Nielsen
kalle@php.net
( Foregot to change address again :( )
Ilia Alshanetsky wrote:
What are your views on including APC in the core, or reasons not to?
Dictatorship?
Optional module which have well used alternatives should not be proced on by
default! Probably more people use alternatives and have for years?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
( Foregot to change address again :( )
Ilia Alshanetsky wrote:What are your views on including APC in the core, or reasons not to?
Dictatorship?
Optional module which have well used alternatives should not be proced on by default! Probably more people use alternatives and have for years?
probably not actually .. my guess is that the vast majority of users do not use any byte code cache today. this could be our effort to reduce co2 emissions world wide.
+1 on adding apc to trunk
+0 about enabling apc by default .. or rather undecided at this point.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
+1 as Lukas, on adding but not enabled by default.
( Foregot to change address again :( )
Ilia Alshanetsky wrote:What are your views on including APC in the core, or reasons not to?
Dictatorship?
Optional module which have well used alternatives should not be proced on by default! Probably more people use alternatives and have for years?probably not actually .. my guess is that the vast majority of users do not use any byte code cache today. this could be our effort to reduce co2 emissions world wide.
+1 on adding apc to trunk
+0 about enabling apc by default .. or rather undecided at this point.regards,
Lukas Kahwe Smith
mls@pooteeweet.org
On Sun, Jun 20, 2010 at 10:39 PM, Lukas Kahwe Smith mls@pooteeweet.orgwrote:
( Foregot to change address again :( )
Ilia Alshanetsky wrote:What are your views on including APC in the core, or reasons not to?
Dictatorship?
Optional module which have well used alternatives should not be proced on
by default! Probably more people use alternatives and have for years?probably not actually .. my guess is that the vast majority of users do not
use any byte code cache today. this could be our effort to reduce co2
emissions world wide.
Are you sure?
Usually installing an opcode cache is the first optimalization effort for
every php project.
I'ts easy, it's transparent, and can give a vast amount of performance
boost, so
- shared hosting providers install it, because they can oversell more
- ppl who can run dedicated server/vps usually knowledgeable enough to
install it right away
+1 on adding apc to trunk
+0 about enabling apc by default .. or rather undecided at this point.
I prefer xcache, but I think that its better adding apc to the core, than
nothing at all.
Why should this be disabled by default?
I never had any problem using xcache. Maybe that it has no gain if you only
use php for cli or cgi.
Tyrael
Perhaps by adding it to core the original reasons for alternatives will be reduced and the things that make those special could be implemented into apc?
On Sun, Jun 20, 2010 at 10:39 PM, Lukas Kahwe Smith mls@pooteeweet.orgwrote:
( Foregot to change address again :( )
Ilia Alshanetsky wrote:What are your views on including APC in the core, or reasons not to?
Dictatorship?
Optional module which have well used alternatives should not be proced on
by default! Probably more people use alternatives and have for years?probably not actually .. my guess is that the vast majority of users do not
use any byte code cache today. this could be our effort to reduce co2
emissions world wide.Are you sure?
Usually installing an opcode cache is the first optimalization effort for
every php project.
I'ts easy, it's transparent, and can give a vast amount of performance
boost, so
- shared hosting providers install it, because they can oversell more
- ppl who can run dedicated server/vps usually knowledgeable enough to
install it right away+1 on adding apc to trunk
+0 about enabling apc by default .. or rather undecided at this point.I prefer xcache, but I think that its better adding apc to the core, than
nothing at all.
Why should this be disabled by default?I never had any problem using xcache. Maybe that it has no gain if you only
use php for cli or cgi.Tyrael
( Foregot to change address again :( )
Ilia Alshanetsky wrote:What are your views on including APC in the core, or reasons not to?
Dictatorship?
Optional module which have well used alternatives should not be proced
on by default! Probably more people use alternatives and have for years?
pecl has been around for years. Nobody else has submitted an opcode
cache to pecl. We certainly would not have rejected any such
submission, and we still won't.
-Rasmus
( Foregot to change address again :( )
Ilia Alshanetsky wrote:What are your views on including APC in the core, or reasons not to?
Dictatorship?
Optional module which have well used alternatives should not be proced
on by default! Probably more people use alternatives and have for years?pecl has been around for years. Nobody else has submitted an opcode
cache to pecl. We certainly would not have rejected any such
submission, and we still won't.
Actually, there is another one: wincache.
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Sure, but that's win32 only
Ilia Alshanetsky
CIO/CSO
Centah Inc.
( Foregot to change address again :( )
Ilia Alshanetsky wrote:What are your views on including APC in the core, or reasons not
to?Dictatorship?
Optional module which have well used alternatives should not be
proced
on by default! Probably more people use alternatives and have for
years?pecl has been around for years. Nobody else has submitted an opcode
cache to pecl. We certainly would not have rejected any such
submission, and we still won't.Actually, there is another one: wincache.
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Ilia Alshanetsky wrote:
Sure, but that's win32 only
Does that matter at present?
http://www.nexdot.net/blog/2010/02/09/wincache-apache-and-a-pretty-graph/
My only objection to bundling yet another package into the core distribution is
that it should be removable as well. eaccelerator works for me so I see no
reason to change from it any time soon, and the performance figures I've been
seeing support that position .... like MySQL .... probably as many people don't
use it as do, so lets keep the core to what is needed, rather than what is
optionally replaceable?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Hi!
Sure, but that's win32 only
Speaking of which - does apc work for Windows? Last time I checked (more
than a year ago) it was extremely unstable. Was it fixed? What about
other popular PHP platforms?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi
2010/6/21 Stas Malyshev smalyshev@sugarcrm.com:
Hi!
Speaking of which - does apc work for Windows? Last time I checked (more
than a year ago) it was extremely unstable. Was it fixed? What about other
popular PHP platforms?
Me and Pierre put quite some work into getting APC to perform much
better on Windows, and I think its well on its way getting there.
regards,
Kalle Sommer Nielsen
kalle@php.net
Rasmus Lerdorf wrote:
( Foregot to change address again :( )
Ilia Alshanetsky wrote:What are your views on including APC in the core, or reasons not to?
Dictatorship?
Optional module which have well used alternatives should not be proced
on by default! Probably more people use alternatives and have for years?pecl has been around for years. Nobody else has submitted an opcode
cache to pecl. We certainly would not have rejected any such
submission, and we still won't.
Well eaccelerator has served me well for years on both Windows and Linux and has
been listed on wikipedia for years before APC was added ;) Just because people
don't like restrictive source management does not mean good code is not available.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Rasmus Lerdorf wrote:
( Foregot to change address again :( )
Ilia Alshanetsky wrote:What are your views on including APC in the core, or reasons not to?
Dictatorship?
Optional module which have well used alternatives should not be proced
on by default! Probably more people use alternatives and have for years?pecl has been around for years. Nobody else has submitted an opcode
cache to pecl. We certainly would not have rejected any such
submission, and we still won't.Well eaccelerator has served me well for years on both Windows and Linux
and has been listed on wikipedia for years before APC was added ;) Just
because people don't like restrictive source management does not mean
good code is not available.
No, it is not enough to just have source code. The developers need to
play along as well.
-Rasmus
Rasmus Lerdorf wrote:
Rasmus Lerdorf wrote:
( Foregot to change address again :( )
Ilia Alshanetsky wrote:What are your views on including APC in the core, or reasons not to?
Dictatorship?
Optional module which have well used alternatives should not be proced
on by default! Probably more people use alternatives and have for years?pecl has been around for years. Nobody else has submitted an opcode
cache to pecl. We certainly would not have rejected any such
submission, and we still won't.Well eaccelerator has served me well for years on both Windows and Linux
and has been listed on wikipedia for years before APC was added ;) Just
because people don't like restrictive source management does not mean
good code is not available.No, it is not enough to just have source code. The developers need to
play along as well.
? eaccelerator is being actively developed, and builds are available for more
versions of windows setup than PHP itself currently supports so the developers
of it are playing along much better then PHP core developers. And a number of
alternatives have also been listed by others. So the question has to be "Why
should APC be given special treatment?" Is it any better than the currently
available alternatives or is it still playing catchup much like PDO?
Perhaps a poll on what people are actually using in production?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
hi,
Perhaps a poll on what people are actually using in production?
The very large majority of the users I met use APC or Zend Cache
solutions. However the point here is that as long as the extension is
not php.net, they won't and can't be considered for inclusion.
Now, about eaccelarator, it is GPL, it is a no-go with PHP.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Several reasons:
-
APC is well maintained, by the same people who work on PHP.
-
The license does not preclude it's inclusion into the base version.
-
most people don't use any opcode cashes, which is not ideal when it
comes to PHP. -
apc inclusion does not prevent alternatives from existing...
Ilia Alshanetsky
CIO/CSO
Centah Inc.
Rasmus Lerdorf wrote:
Rasmus Lerdorf wrote:
( Foregot to change address again :( )
Ilia Alshanetsky wrote:What are your views on including APC in the core, or reasons
not to?Dictatorship?
Optional module which have well used alternatives should not be
proced
on by default! Probably more people use alternatives and have
for years?pecl has been around for years. Nobody else has submitted an
opcode
cache to pecl. We certainly would not have rejected any such
submission, and we still won't.Well eaccelerator has served me well for years on both Windows and
Linux
and has been listed on wikipedia for years before APC was added ;)
Just
because people don't like restrictive source management does not
mean
good code is not available.No, it is not enough to just have source code. The developers need
to
play along as well.? eaccelerator is being actively developed, and builds are available
for more versions of windows setup than PHP itself currently
supports so the developers of it are playing along much better then
PHP core developers. And a number of alternatives have also been
listed by others. So the question has to be "Why should APC be given
special treatment?" Is it any better than the currently available
alternatives or is it still playing catchup much like PDO?Perhaps a poll on what people are actually using in production?
--
Lester Caine - G8HFLContact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
"Ilia Alshanetsky" ilia@prohost.org wrote in message
news:86A0C51A-E6F7-48F2-A065-EABE74C6A71A@prohost.org...
Several reasons:
APC is well maintained, by the same people who work on PHP.
The license does not preclude it's inclusion into the base version.
most people don't use any opcode cashes, which is not ideal when it
comes to PHP.apc inclusion does not prevent alternatives from existing...
Ilia Alshanetsky
CIO/CSO
Centah Inc.
Ilia,
-the fact that APC is well maintained is not a strong argument because the
other php opcode caches are well-maintained too.
Well, better or worse, that's the question. Do you by any chance have any
numbers to compare that would prove your argument?
-the license is compatible? Well, let's move into php core everything that
has a compatible license! So it is not an agurment either.
(the opposite would be a strong arument because nothing with incompatible
license could be added)
-most people do not use caches? To me it's not exactly correct. Did you hear
of XAMPP or WAMPP packages for Windows? Did you check the modules they
distribute? How many opcode caches do they deliver? At least three AFAIK.
That's Windows. About BSD - did you try to compile php from ports on BSD*
alike systems? Didn't you notice APC among the options? As of Linux, APC is
a module officially included with all major distributions. What would change
for the end-user if you move APC into trunk? From these perspectives -- very
little to nothing.
-p.4 reminds me Microsoft's policy. The next step would be to create a trick
in the API that will prevent the others from working, but APC :)
It's my understanding <grin> that "people do not use opcode caches" not
because they don't really use it, but because you are not aware of it :)
People who are aware of opcode caches do really use them, not necessarily
"the state of art and mainentance" APC. They mostly use eaccelerator and
xcache, successors of Dmitry Stogov's turck mmcache.
Who are not aware of opcode caches won't use them anyway until you FORCE
them to use it. But you're not FORCING, right?
If you move APC into php trunk, nothing will really change: only name of the
module would lose its pecl part in the name and size of sources will
increase and...
Now a bit more serious moment:
Since APC modifies behaviour of php core and it comes side-by-side with php
core (from the trunk!), it's stability can't be left over. The release
manager won't be able to release any further version of PHP without knowing
for sure that APC is still compatible with the other changes and it works,
and php works with cached opcodes, so the testers will have to run all tests
at least twice, and do this under php SAPI that works with APC using shared
memory, which is not the case if command-line php is used AFAIK.
From these perspectives, the benefits are not sensible, while negative
impact is obvious.
If you want people to be more aware of APC and use it more frequently, why
not to add visiblity to APC, why not to write articles, show benefits in PHP
conferences, etc. In other words, why not to go by a usual way?
just my 2c
-jv
PS while some people are fighting for core of their projects to be as small
as possible, php people are going by their own way: removing mysql extension
that most people are using, and replacing it with APC that a very few would
like to use... That's pity and funny.
Including into core of PHP has no impact on other opcode caches, if
they do a better job then APC, people can definitely (and should) use
them. The main purpose of including APC would be to raise the level of
awareness PHP users to the fact opcode caches exist and should be used
in virtually all instances where PHP is used.
Most people do not use opcode, I know it from asking that question at
just about every conference. As if you do a google query searching for
phpinfo() and try to find those with any cache, you'll see that there
are FAR fewer of those then those without any caching being enabled.
Just because APC package exists on most linux and BSD distros does not
mean people know what it is, you have lots of extensions that are
available as packages...
How is adding an extension forcing anyone to use, dba extension has
been in core in ages, and only people who choose to use it do... "in
core" does not mean that you must use it.
"Ilia Alshanetsky" ilia@prohost.org wrote in message
news:86A0C51A-E6F7-48F2-A065-EABE74C6A71A@prohost.org...Several reasons:
APC is well maintained, by the same people who work on PHP.
The license does not preclude it's inclusion into the base version.
most people don't use any opcode cashes, which is not ideal when it
comes to PHP.apc inclusion does not prevent alternatives from existing...
Ilia Alshanetsky
CIO/CSO
Centah Inc.Ilia,
-the fact that APC is well maintained is not a strong argument because the
other php opcode caches are well-maintained too.
Well, better or worse, that's the question. Do you by any chance have any
numbers to compare that would prove your argument?-the license is compatible? Well, let's move into php core everything that
has a compatible license! So it is not an agurment either.
(the opposite would be a strong arument because nothing with incompatible
license could be added)-most people do not use caches? To me it's not exactly correct. Did you hear
of XAMPP or WAMPP packages for Windows? Did you check the modules they
distribute? How many opcode caches do they deliver? At least three AFAIK.
That's Windows. About BSD - did you try to compile php from ports on BSD*
alike systems? Didn't you notice APC among the options? As of Linux, APC is
a module officially included with all major distributions. What would change
for the end-user if you move APC into trunk? From these perspectives -- very
little to nothing.-p.4 reminds me Microsoft's policy. The next step would be to create a trick
in the API that will prevent the others from working, but APC :)It's my understanding <grin> that "people do not use opcode caches" not
because they don't really use it, but because you are not aware of it :)
People who are aware of opcode caches do really use them, not necessarily
"the state of art and mainentance" APC. They mostly use eaccelerator and
xcache, successors of Dmitry Stogov's turck mmcache.
Who are not aware of opcode caches won't use them anyway until you FORCE
them to use it. But you're not FORCING, right?If you move APC into php trunk, nothing will really change: only name of the
module would lose its pecl part in the name and size of sources will
increase and...
Now a bit more serious moment:
Since APC modifies behaviour of php core and it comes side-by-side with php
core (from the trunk!), it's stability can't be left over. The release
manager won't be able to release any further version of PHP without knowing
for sure that APC is still compatible with the other changes and it works,
and php works with cached opcodes, so the testers will have to run all tests
at least twice, and do this under php SAPI that works with APC using shared
memory, which is not the case if command-line php is used AFAIK.From these perspectives, the benefits are not sensible, while negative
impact is obvious.If you want people to be more aware of APC and use it more frequently, why
not to add visiblity to APC, why not to write articles, show benefits in PHP
conferences, etc. In other words, why not to go by a usual way?just my 2c
-jvPS while some people are fighting for core of their projects to be as small
as possible, php people are going by their own way: removing mysql extension
that most people are using, and replacing it with APC that a very few would
like to use... That's pity and funny.
Rasmus Lerdorf wrote:
Rasmus Lerdorf wrote:
( Foregot to change address again :( )
Ilia Alshanetsky wrote:What are your views on including APC in the core, or reasons not to?
Dictatorship?
Optional module which have well used alternatives should not be proced
on by default! Probably more people use alternatives and have for
years?pecl has been around for years. Nobody else has submitted an opcode
cache to pecl. We certainly would not have rejected any such
submission, and we still won't.Well eaccelerator has served me well for years on both Windows and Linux
and has been listed on wikipedia for years before APC was added ;) Just
because people don't like restrictive source management does not mean
good code is not available.No, it is not enough to just have source code. The developers need to
play along as well.? eaccelerator is being actively developed, and builds are available for
more versions of windows setup than PHP itself currently supports so the
developers of it are playing along much better then PHP core developers.
And a number of alternatives have also been listed by others. So the
question has to be "Why should APC be given special treatment?" Is it
any better than the currently available alternatives or is it still
playing catchup much like PDO?
But they haven't made any attempts to add it to pecl nor release it
under a license that would even make it possible to include in PHP.
That's what I meant by playing along.
-Rasmus
Am 20.06.2010 23:07, schrieb Rasmus Lerdorf:
No, it is not enough to just have source code. The developers need to
play along as well.
Which reminds me: does anybody actually know who develops xcache? Last
time I checked the answer I found was: moo.
--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
What's the problem with moo?
Tyrael
On Mon, Jun 21, 2010 at 8:49 AM, Sebastian Bergmann <
sb@sebastian-bergmann.de> wrote:
Am 20.06.2010 23:07, schrieb Rasmus Lerdorf:
No, it is not enough to just have source code. The developers need to
play along as well.Which reminds me: does anybody actually know who develops xcache? Last
time I checked the answer I found was: moo.--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
Am 21.06.2010 09:33, schrieb Ferenc Kovacs:
What's the problem with moo?
You are not seriously asking that question, are you?
--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
I for one think it is a really good idea, there is no compelling
reason not to include APC, I would even go as far as say we should
enable it by default.
I would like to add it as well; but not turn it on by default. Not
because it wouldn't be good, but more because it requires (a bit of)
configuration.
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Hi!
I for one think it is a really good idea, there is no compelling
reason not to include APC, I would even go as far as say we should
enable it by default.
I do not think it is a very good idea. APC has certain effects on the
code that are far from obvious, and enabling it by default would
significantly complicate the average user's learning curve.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
APC has certain effects on the code that are far from obvious, and
enabling it by default would significantly complicate the average
user's learning curve.
Can you elaborate? What "average user"-facing features are non-obvious?
We should document them if nothing else.
S
Hi!
Can you elaborate? What "average user"-facing features are non-obvious?
We should document them if nothing else.
This recently caught my attention: http://pecl.php.net/bugs/bug.php?id=16745
As I understood from this bug, APC changes how PHP works (since it works
without APC but not with it) and it is not considered a problem in APC.
Which means enabling APC by default is a BC break, and there's already a
proof that it breaks real-life code (even if particular code had been
changed to work with it, the fact that APC can break otherwise working
code stays). Now probably most of the experienced users wouldn't mind
fixing the code a bit, but for enabling by default it should be 100% BC.
apc.file_update_protection could have some unexpected results too.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Stas,
Even if the extension is compiled by default, we can (and probably
should) leave apc.enabled at Off, recognizing some the things you are
mentioning.
Hi!
Can you elaborate? What "average user"-facing features are non-obvious?
We should document them if nothing else.This recently caught my attention: http://pecl.php.net/bugs/bug.php?id=16745
As I understood from this bug, APC changes how PHP works (since it works
without APC but not with it) and it is not considered a problem in APC.
Which means enabling APC by default is a BC break, and there's already a
proof that it breaks real-life code (even if particular code had been
changed to work with it, the fact that APC can break otherwise working code
stays). Now probably most of the experienced users wouldn't mind fixing the
code a bit, but for enabling by default it should be 100% BC.apc.file_update_protection could have some unexpected results too.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
Even if the extension is compiled by default, we can (and probably
should) leave apc.enabled at Off, recognizing some the things you are
mentioning.
I'm not sure I see the point of compiling it if it's disabled. Anyway,
most of the distributions probably would make it .so just as it happens
now for tons of other modules and would enable it in .ini. And building
it from source you almost never rely on defaults anyway if you know what
you want (which is the reason why you didn't use the binary one, I
guess). So, summarily, I don't think we should enable it by default, as
for compiling it by default, I don't think it matters too much since I
don't believe defaults matter too much there.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
The point is that it would be there for people to use, with as little
effort as possible, which would be changing 1 byte inside the INI
file. The issues APC is having with certain code is not specific to
APC, and does happen with other open source caches. Perhaps we need to
examine the validity of that code, or simply not cache the code that's
affected.
Hi!
Even if the extension is compiled by default, we can (and probably
should) leave apc.enabled at Off, recognizing some the things you are
mentioning.I'm not sure I see the point of compiling it if it's disabled. Anyway, most
of the distributions probably would make it .so just as it happens now for
tons of other modules and would enable it in .ini. And building it from
source you almost never rely on defaults anyway if you know what you want
(which is the reason why you didn't use the binary one, I guess). So,
summarily, I don't think we should enable it by default, as for compiling it
by default, I don't think it matters too much since I don't believe defaults
matter too much there.Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
The point is that it would be there for people to use, with as little
effort as possible, which would be changing 1 byte inside the INI
file. The issues APC is having with certain code is not specific to
APC, and does happen with other open source caches. Perhaps we need to
We don't discuss putting other OSS (or non-OSS for that matter :) caches
in any PHP build, enabled by default, do we? That's the point.
And really, enabling extension - either in source build or in binary
build - is not that hard. If they are able to write PHP, they should be
able to remove ; before extension= or write --enable-apc.
examine the validity of that code, or simply not cache the code that's
affected.
I'd rather not make such kludges, especially if we talk about main PHP
source. It's not a good road to take.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Stas,
If there is a better alternative to APC we can bundle with PHP, I am
definitely open to exploring that idea. However the alternatives I am
familiar either are closed source or have licences incompatible with
PHP, and that's without getting into the "better" argument.
Hi!
The point is that it would be there for people to use, with as little
effort as possible, which would be changing 1 byte inside the INI
file. The issues APC is having with certain code is not specific to
APC, and does happen with other open source caches. Perhaps we need toWe don't discuss putting other OSS (or non-OSS for that matter :) caches in
any PHP build, enabled by default, do we? That's the point.
And really, enabling extension - either in source build or in binary build -
is not that hard. If they are able to write PHP, they should be able to
remove ; before extension= or write --enable-apc.examine the validity of that code, or simply not cache the code that's
affected.I'd rather not make such kludges, especially if we talk about main PHP
source. It's not a good road to take.Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
If there is a better alternative to APC we can bundle with PHP, I am
definitely open to exploring that idea. However the alternatives I am
familiar either are closed source or have licences incompatible with
PHP, and that's without getting into the "better" argument.
I don't know any better one, but this is not what I am talking about. I
am talking about enabling it by default - and I'm saying it seems to me
dangerous now. That doesn't mean APC is worse than something else - it
just means something enabled by default in PHP has (or should have)
higher requirements than something that'd be compiled by people that
need it when they need it - as it happens now. I don't see a pressing
need to have some bytecode cache enabled by default in any build of PHP.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
"Ilia Alshanetsky" ilia@prohost.org wrote in message
news:AANLkTilzlbBFucUV-jtmkM-QljL1il7WSqY0fYhn3JXC@mail.gmail.com...
Including into core of PHP has no impact on other opcode caches, if
they do a better job then APC, people can definitely (and should) use
them. The main purpose of including APC would be to raise the level of
awareness PHP users to the fact opcode caches exist and should be used
in virtually all instances where PHP is used.Most people do not use opcode, I know it from asking that question at
just about every conference. As if you do a google query searching for
phpinfo()and try to find those with any cache, you'll see that there
are FAR fewer of those then those without any caching being enabled.Just because APC package exists on most linux and BSD distros does not
mean people know what it is, you have lots of extensions that are
available as packages...How is adding an extension forcing anyone to use, dba extension has
been in core in ages, and only people who choose to use it do... "in
core" does not mean that you must use it.
Obviously, the target should not and could not be to just improve the
awareness of opcode caches.
If you want to improve the awareness, there are many ways that would leave
all competing caches under the same equal conditions.
For example, add a table on pecl.php.net: ten most popular pecl extensions
and duplicate it on php.net. As soon as APC appeared there, it will be seen
and all people will be aware.
If people behind XCache or eAccelerator decide to move in this direction,
they would make the license compatible
and bring their code into pecl. Isn't it a right way amongst many other
right ways?
How would a disabled and potentially even not installed php extension affect
awareness?
In fact, you can add APC into trunk and you can remove it, nothing will
change on a particular platform until
the OS vendor (like RedHat) will move or remove the module into/from php
package, and what they will do is not that obvious.
Try to talk to them first: are they ready for the change?
Adding APC into trunk makes it preferrable while the choise is based on the
fact that one of the people behind APC is the php creator.
After all, I'd love to see Zend's people opinion posted on this thread. In
particular Zeev's and/or Andi's. Dmitry should be listened too.
You didn't answer to the question about problems with further php
mainentability.
How the releases process of PHP will be changed? What will be done in order
to keep APC as bug-free as PHP CORE which functionality APC affects.
-jv
Stas,
If there is a better alternative to APC we can bundle with PHP, I am
definitely open to exploring that idea. However the alternatives I am
familiar either are closed source or have licences incompatible with
PHP, and that's without getting into the "better" argument.
As a PHP user, when moving to PHP 5.3, from 5.2 I had the question
regarding which accel to use (I had been using APC). From most
of what I read, APC was not compatible and looking at the APC site,
the last 'stable' release was ~2years ago with a bunch of betas. I
then looked at XCache and saw that it was "more maintained" as well
as explicitly mentioned PHP 5.3 compatibility.
In other words, to the unwashed masses, XCache, for example,
seemed a "better" and "safer" choice than APC, despite the
list of names attached to the latter. Certainly I would have
preferred staying with APC but it sure seemed like it was
a side project that people just lost interest in... Moving it
to be an actual part of PHP would go a LOOOONG way in showing
others that APC is a serious codebase again.
===========================================================================
Jim Jagielski [|] jim@jaguNET.com [|] http://www.jaguNET.com/
"Great is the guilt of an unnecessary war" ~ John Adams
As a PHP user, when moving to PHP 5.3, from 5.2 I had the question
regarding which accel to use (I had been using APC). From most
of what I read, APC was not compatible and looking at the APC site,
the last 'stable' release was ~2years ago with a bunch of betas. I
then looked at XCache and saw that it was "more maintained" as well
as explicitly mentioned PHP 5.3 compatibility.In other words, to the unwashed masses, XCache, for example,
seemed a "better" and "safer" choice than APC, despite the
list of names attached to the latter.
We've been experiencing some troubles with APC + 5.3, too,
so I tried switching to XCache and my experience is described here:
http://xcache.lighttpd.net/ticket/240
Judging by XCache SVN, there were no changes since then.
So we're still using APC + 5.3 in production, even though
I get a core now and then (weird, last segfault was ~2 weeks ago..).
--
Wbr,
Antony Dovgal
http://pinba.org - realtime statistics for PHP
I would like to know why a third party can develop a better (or more agile?) cache than the core php devs. I would think that if anyone can align it nicely especially when writing the core code itself and could also think about "this is a great place for apc to hook in" or something. It's obvious due to the strong feelings that this is a controversial point due to how well other options work. As a user myself I have to ask "why can't there be one that encompasses all the best of all of them"
As a PHP user, when moving to PHP 5.3, from 5.2 I had the question
regarding which accel to use (I had been using APC). From most
of what I read, APC was not compatible and looking at the APC site,
the last 'stable' release was ~2years ago with a bunch of betas. I
then looked at XCache and saw that it was "more maintained" as well
as explicitly mentioned PHP 5.3 compatibility.In other words, to the unwashed masses, XCache, for example,
seemed a "better" and "safer" choice than APC, despite the
list of names attached to the latter.We've been experiencing some troubles with APC + 5.3, too,
so I tried switching to XCache and my experience is described here:
http://xcache.lighttpd.net/ticket/240
Judging by XCache SVN, there were no changes since then.So we're still using APC + 5.3 in production, even though
I get a core now and then (weird, last segfault was ~2 weeks ago..).--
Wbr,
Antony Dovgalhttp://pinba.org - realtime statistics for PHP
Hi!
Can you elaborate? What "average user"-facing features are non-obvious?
We should document them if nothing else.This recently caught my attention:
http://pecl.php.net/bugs/bug.php?id=16745
As I understood from this bug, APC changes how PHP works (since it works
without APC but not with it) and it is not considered a problem in APC.
Which means enabling APC by default is a BC break, and there's already a
proof that it breaks real-life code (even if particular code had been
changed to work with it, the fact that APC can break otherwise working
code stays). Now probably most of the experienced users wouldn't mind
fixing the code a bit, but for enabling by default it should be 100% BC.
This is an unfixed PHP bug. There have been a number of threads about
the object destruction order on internals. It isn't just APC that is
affected by this. Other extensions are affected as well.
apc.file_update_protection could have some unexpected results too.
Not any that change the behaviour of PHP.
-Rasmus
Hi!
This is an unfixed PHP bug. There have been a number of threads about
the object destruction order on internals. It isn't just APC that is
affected by this. Other extensions are affected as well.
I understand that this effect is caused by the fact that APC destroys
PHP classes earlier than PHP engine otherwise would. You can claim it's
a bug but then until it's fixed enabling APC would still cause BC break,
and no amount of renaming this fact would change it.
If we can fix it and make it work properly - fine, then this ojection
ceases to exist as soon as it's done, if there's no more cases when APC
behaves differently.
apc.file_update_protection could have some unexpected results too.
Not any that change the behaviour of PHP.
Do I misunderstand how this feature works? I was under impression that
it prevents APC from updating the file for X seconds since its
modification - while plain PHP of course would see the change instantly.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
This is an unfixed PHP bug. There have been a number of threads about
the object destruction order on internals. It isn't just APC that is
affected by this. Other extensions are affected as well.I understand that this effect is caused by the fact that APC destroys PHP classes earlier than PHP engine otherwise would. You can claim it's a bug but then until it's fixed enabling APC would still cause BC break, and no amount of renaming this fact would change it.
If we can fix it and make it work properly - fine, then this ojection ceases to exist as soon as it's done, if there's no more cases when APC behaves differently.
I am still undecided if to enable by default, but originally the idea was to bundle with PHP 6, and I think this type of BC break in an edge feature (or rather edge bug) would be ok in a major update to the language.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
This is an unfixed PHP bug. There have been a number of threads about
the object destruction order on internals. It isn't just APC that is
affected by this. Other extensions are affected as well.I understand that this effect is caused by the fact that APC destroys PHP
classes earlier than PHP engine otherwise would. You can claim it's a bug
but then until it's fixed enabling APC would still cause BC break, and no
amount of renaming this fact would change it.
If we can fix it and make it work properly - fine, then this ojection
ceases to exist as soon as it's done, if there's no more cases when APC
behaves differently.I am still undecided if to enable by default, but originally
the idea was to bundle with PHP 6, and I think this type
of BC break in an edge feature (or rather edge bug) would be ok in a major
update to the language.
If I get it right, the BC break will depend on whether apc is enabled or
not.
So, it's not major update brings the breach.
-jv
Hi!
Can you elaborate? What "average user"-facing features are non-obvious?
We should document them if nothing else.This recently caught my attention:
http://pecl.php.net/bugs/bug.php?id=16745
As I understood from this bug, APC changes how PHP works (since it works
without APC but not with it) and it is not considered a problem in APC.
Which means enabling APC by default is a BC break, and there's already a
proof that it breaks real-life code (even if particular code had been
changed to work with it, the fact that APC can break otherwise working
code stays). Now probably most of the experienced users wouldn't mind
fixing the code a bit, but for enabling by default it should be 100% BC.
By the way, including APC in the core is actually likely to fix this
problem because it has to do with the order the rshutdown functions are
called. Read Christian's excellent description of the problem here:
http://news.php.net/php.internals/46999
-Rasmus
I for one think it is a really good idea, there is no compelling
reason not to include APC, I would even go as far as say we should
enable it by default.+1
We'd need to get http://wiki.php.net/rfc/zendsignals committed before we even get it in the core.
At the moment if the script gets killed while the cache was being cleaned it up it never unlocks it and your server is essentially dead.
- S
I for one think it is a really good idea, there is no compelling
reason not to include APC, I would even go as far as say we should
enable it by default.+1
We'd need to get http://wiki.php.net/rfc/zendsignals committed before we even get it in the core.
At the moment if the script gets killed while the cache was being cleaned it up it never unlocks it and your server is essentially dead.
Depends on the locking mechanism. As long as you have owner-death
protection in your lock, you are fine for this particular problem.
-Rasmus
I for one think it is a really good idea, there is no compelling
reason not to include APC, I would even go as far as say we should
enable it by default.+1
We'd need to get http://wiki.php.net/rfc/zendsignals committed before we even get it in the core.
At the moment if the script gets killed while the cache was being cleaned it up it never unlocks it and your server is essentially dead.
Depends on the locking mechanism. As long as you have owner-death
protection in your lock, you are fine for this particular problem.
shire's patch was fine, I think the only thing missing from it was Windows support though tbh its no worse than what is there before.
- S
"Rasmus Lerdorf" rasmus@lerdorf.com wrote in message
news:4C1ED90D.2030707@lerdorf.com...
Hi!
Can you elaborate? What "average user"-facing features are non-obvious?
We should document them if nothing else.This recently caught my attention:
http://pecl.php.net/bugs/bug.php?id=16745
As I understood from this bug, APC changes how PHP works (since it works
....By the way, including APC in the core is actually likely to fix this
problem because it has to do with the order the rshutdown functions are
called. Read Christian's excellent description of the problem here:http://news.php.net/php.internals/46999
-Rasmus
concerting http://news.php.net/php.internals/46999
If APC is that well-maintained as many people impressed here, why this
rather simple bug is still not fixed during the year?
Why the other php opcode caches do NOT impose similar problems?
Isn't it yet another reason not to add APC into the core?
Doesn't it plainly show that there is no benefits from the fact that people
behind APC are known?
-jv
hi,
"Rasmus Lerdorf" rasmus@lerdorf.com wrote in message
news:4C1ED90D.2030707@lerdorf.com...Hi!
Can you elaborate? What "average user"-facing features are non-obvious?
We should document them if nothing else.This recently caught my attention:
http://pecl.php.net/bugs/bug.php?id=16745
As I understood from this bug, APC changes how PHP works (since it works
....By the way, including APC in the core is actually likely to fix this
problem because it has to do with the order the rshutdown functions are
called. Read Christian's excellent description of the problem here:http://news.php.net/php.internals/46999
-Rasmus
concerting http://news.php.net/php.internals/46999
If APC is that well-maintained as many people impressed here, why this
rather simple bug is still not fixed during the year?
Thanks to volunteer to fix this bug. Please attach patch to the bug report.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
By the way, including APC in the core is actually likely to fix this
problem because it has to do with the order the rshutdown functions are
called. Read Christian's excellent description of the problem here:http://news.php.net/php.internals/46999
-Rasmus
concerting http://news.php.net/php.internals/46999
If APC is that well-maintained as many people impressed here, why this
rather simple bug is still not fixed during the year?Thanks to volunteer to fix this bug. Please attach patch to the bug report.
keep on the topic pls, which is the inclusion of potentially buggy and
poorly maintained APC.
keep on the topic pls, which is the inclusion of potentially buggy and
poorly maintained APC.
I'm on topic. You seem to be able to fix this bug very easily, I only
told you how to provide patches.
APC is well maintained but all I can read from you are some random
bashing about non APC specific bugs.
APC is the only opcode cache available at php.net and under a very
permissive license (aka PHP's). You may like other options more than
APC but that's definitively not arguments against APC.
If you have specific issues with APC or specific cases to show how APC
is poorly maintained, then please raise them.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
keep on the topic pls, which is the inclusion of potentially buggy and
poorly maintained APC.I'm on topic. You seem to be able to fix this bug very easily, I only
told you how to provide patches.
I do not care of bugs in APC unless this module is NOT in php core.
If they appear in php core, I'll decide whether php is a right way for me to
go at all.
APC is well maintained but all I can read from you are some random
bashing about non APC specific bugs.
Know what? APC is wrongly designed as a php extension which does not allow
it to catch certain things at certain time, so it is definitely bug in APC.
The fact that the other opcode caches do not suffer from this bug being
installed as zend extension only prove that the bug is in APC and it is
poory maintained.
APC is the only opcode cache available at php.net and under a very
permissive license (aka PHP's). You may like other options more than
APC but that's definitively not arguments against APC.
License argument does not work at all.
Many years ago the first php debugger DBG was released under PHP license
but it didn't allow Rasmus and Zeev to merge it into the core even though
the formal request was published on php.internals.
What was changed since that, Pierre?
Or the extension author/maintainer should be only Rasmus and Zeev to get it
into the core?
If you have specific issues with APC or specific cases to show how APC
is poorly maintained, then please raise them.
Try to understand the arguments above.
-jv
keep on the topic pls, which is the inclusion of potentially buggy and
poorly maintained APC.I'm on topic. You seem to be able to fix this bug very easily, I only
told you how to provide patches.I do not care of bugs in APC unless this module is NOT in php core.
If they appear in php core, I'll decide whether php is a right way for me to
go at all.
This bug is not APC specific.
APC is well maintained but all I can read from you are some random
bashing about non APC specific bugs.Know what? APC is wrongly designed as a php extension which does not allow
it to catch certain things at certain time, so it is definitely bug in APC.
Certain thing at certain time? Ok.
License argument does not work at all.
It does, more than ever.
But I think we have now got the idea, you don't like APC. Point made
(or at least said).
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
This bug is not APC specific.
In this case you can easily point out to another module suffering from this
bug, don't you?
License argument does not work at all.
It does, more than ever.
Then is there any reason not to add all code compatible in php license terms
into php core?
If not, what did stop from adding DBG debugger?
But I think we have now got the idea, you don't like APC. Point made
(or at least said).
Pierre, I understand your position toward APC and you won't accept any
criticism and will see only what you like to see.
In fact there is nothing personal. I like APC in its current place and its
role is visible to me. I am aware of APC as well as all other publicly
avalable php opcode caches such as xcache, eaccelerator, phpexpress.
What I don't like is the idea of providing preferences to an extension among
the others playing the same role, especially taking into account that the
particular extension is not the best among the others.
I don't like the idea of solving marketing tasks such as increasing
visibility and awareness by such manipulations like adding NOT required and
poorly maintained code into the core.
This approach will only reduce competition and will shrink the market.
-jv
hi,
This bug is not APC specific.
In this case you can easily point out to another module suffering from this
bug, don't you?License argument does not work at all.
It does, more than ever.
Then is there any reason not to add all code compatible in php license terms
into php core?
What are you talking about? Who said that we have to add any php
licensed code to the core? I only said that the license is a critical
part of the decision. Nothing else.
Pierre, I understand your position toward APC
How can you understand something I did not even mention (if I like or
not to bundle APC)?
and you won't accept any
criticism and will see only what you like to see.
I do accept criticism as well, when constructive. And that's sadly not
the case here, I don't see any kind of actual bugs or issues but some
random complaints. My replies are only about getting the facts behind
"not maintained" and "buggy". I'm still waiting for them.
This approach will only reduce competition and will shrink the market.
As of now the only competitor actually reducing competition is Zend
(no offense meant to the Zend guys), and the reasons are not technical
but marketing related. I don't think we can do anything like that or
anything against that.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Then is there any reason not to add all code compatible in php license
terms
into php core?What are you talking about? Who said that we have to add any php
licensed code to the core? I only said that the license is a critical
part of the decision. Nothing else.
APC can be added, this fact does not mean that it should be added.
So the license compatibility argument is neutral for adding or not adding
APC.
This approach will only reduce competition and will shrink the market.
As of now the only competitor actually reducing competition is Zend
(no offense meant to the Zend guys), and the reasons are not technical
but marketing related. I don't think we can do anything like that or
anything against that.
I didn't see any attempts from Zend to add NOT REQUIRED PHP MODULES into the
core.
They are going by a clear way and their efforts can't be underestimated.
As I see they are changing the core in a right way: check for example
zend_vm_xxx added in 5.1,
check the proposed and implemented improvements in memory management etc.
This all makes php position on the market stronger, so the competition
between php and
the other web-languages is NOT reduced by Zend efforts.
Competition between opcode caches for php will definitely be reduced by
adding APC into the core,
so the market will shrink, of course.
What can be further done for php performance improvements (if you care of it
at all) is garbage collector, copy-on-write, and possibly jit compiler for
some platforms.
These techniques will put php on par with the best propriatary languages
available for the web, or may be will make php even better.
Meanwhile the benefit comming with php is a balance between cost, features,
and stability. Don't break it.
As of adding APC into the core, I expect more problems to come and nothing
would be solved.
-jv
Competition between opcode caches for php will definitely be reduced by
adding APC into the core,
so the market will shrink, of course.
i think this is a likely outcome indeed. it might also be phrased in a more positive tone in that likely efforts will be joined. for example maybe zend will decide to contribute some of their code to APC.
so the key question might be more is there something in APC that makes it fundamentally the right or wrong approach.
furthermore does adding any byte code cache to core also enable new kinds of optimizations because its now possible to more tightly integrate with core?
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Competition between opcode caches for php will definitely be reduced by
adding APC into the core,
so the market will shrink, of course.i think this is a likely outcome indeed. it might also be phrased in a
more
positive tone in that likely efforts will be joined. for example maybe
zend
will decide to contribute some of their code to APC.
my poor english does not allow me to impress it clearly that my tone is as
positive as possible :)
so the key question might be more is there something in APC that makes
it fundamentally the right or wrong approach.
Is there any possibility for you or anybody else to run all php standard
tests under Apache + php
with and without APC to see how many among them are broken with APC?
Please don't forget to run tests TWICE under APC because on the first run it
does not use the cached opcodes.
furthermore does adding any byte code cache to core also enable new kinds
of optimizations
because its now possible to more tightly integrate with core?
I'd think of tightly integrated opcode serializer/deserializer and it's what
can be highly optimized after adding into the core.
This approach would be much cleaner, indeed.
-jv
I for one think it is a really good idea, there is no compelling
reason not to include APC, I would even go as far as say we should
enable it by default.
+1 on adding into the distro
-1 on enabling by default
--
Wbr,
Antony Dovgal
http://pinba.org - realtime statistics for PHP
Am 20.06.2010 20:21, schrieb Ilia Alshanetsky:
I for one think it is a really good idea, there is no compelling
reason not to include APC, I would even go as far as say we should
enable it by default.
+1 for bundling
+1 for removing the "layer of checks for macros" for PHP <= 5.4
+1 for building it by default
-1 for enabling it by default
--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
2010/6/21 Sebastian Bergmann sb@sebastian-bergmann.de:
Am 20.06.2010 20:21, schrieb Ilia Alshanetsky:
I for one think it is a really good idea, there is no compelling
reason not to include APC, I would even go as far as say we should
enable it by default.+1 for bundling
+1 for removing the "layer of checks for macros" for PHP <= 5.4
+1 for building it by default
-1 for enabling it by default
Double those votes!
Patrick
--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
Ilia Alshanetsky wrote:
I for one think it is a really good idea, there is no compelling
reason not to include APC, I would even go as far as say we should
enable it by default.+1
+1 for including APC
-1 for enabling by default
It was already agreed to include it into 6 before so why the need for
another vote on this just because its a new trunk?
Rob
Same here.
+1 to bundle
-1 to enable it by default
Ilia Alshanetsky wrote:
I for one think it is a really good idea, there is no compelling
reaso...
+1 for including APC
-1 for enabling by default
It was already agreed to include it into 6 before so why the need for
another vote on this just because its a new trunk?
Rob
--
To unsubscribe, visit: http://www.php.net/unsub...
At 14:09 21/06/2010, Pierre Joye wrote:
Same here.
+1 to bundle
-1 to enable it by default
Slightly late to the game but my view is the same, +1 to bundle, -1
to enable by default.
Zeev
At 14:09 21/06/2010, Pierre Joye wrote:
Same here.
+1 to bundle
-1 to enable it by defaultSlightly late to the game but my view is the same, +1 to bundle, -1 to enable by default.
Is it too late to discuss the topic of leaving extensions in PECL, and bundling [some] near release time? Maybe Trunk could begin that idealistic revolution?
Regards,
Philip
Am 21.06.2010 13:05, schrieb Rob Richards:
It was already agreed to include it into 6 before so why the need for
another vote on this just because its a new trunk?
Also eludes me :-)
--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
From my point-of-view as a developer (and occasional sysadmin) this is
something which I have been looking forward too for some time so
+1 for including in core
+1 for compiling but not enabling
Marco
Can we deduct from that a 6 version number for trunk? :) just kidding
I am also +1 on bundle but not on default. I think we should also reach out to other OSS caches to ensure they know they still have a place in our Eco system. Some are preferred by certain use cases.
Am 21.06.2010 13:05, schrieb Rob Richards:
It was already agreed to include it into 6 before so why the need for
another vote on this just because its a new trunk?Also eludes me :-)
--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
Greetings
What are your views on including APC in the core, or reasons not to?
+1 moving it into core
-1 enabling by default
What are your views on including APC in the core, or reasons not to?
+1 Added to core
-1 Enabled by default
If APC is not as stable on Windows as required AND licensing issues
are resolvable, could WinCache for Windows be an option? That is added
to code but not enabled?
--
Richard Quadling
"Standing on the shoulders of some very clever giants!"
EE : http://www.experts-exchange.com/M_248814.html
EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling
Hi
It seems like theres been enough votes for moving it to the core, is
there anyone willing to make that change? Rasmus or Derick? We can
always decide whether to enable it by default afterwards.
As for enabled it by default, I think it should be okay to atleast
enable it as a shared extension by default, atleast on Windows, like
GD is.
--
regards,
Kalle Sommer Nielsen
kalle@php.net
It seems like theres been enough votes for moving it to the core, is
there anyone willing to make that change? Rasmus or Derick? We can
always decide whether to enable it by default afterwards.
I can do it; but the question is whether we want to use APC 3.x or 4.x
in trunk? Gopal, Rasmus?
regards,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
hi,
It seems like theres been enough votes for moving it to the core, is
there anyone willing to make that change? Rasmus or Derick? We can
always decide whether to enable it by default afterwards.I can do it; but the question is whether we want to use APC 3.x or 4.x
in trunk? Gopal, Rasmus?
For one, I would prefer to see 4.x but I'm not sure it is ready yet.
However 4.x also needs the changes applied to support recent
optimizations in the engine (they have been applied to trunk only). I
would suggest to do the merges prior to include it.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
It seems like theres been enough votes for moving it to the core, is
there anyone willing to make that change? Rasmus or Derick? We can
always decide whether to enable it by default afterwards.I can do it; but the question is whether we want to use APC 3.x or 4.x
in trunk? Gopal, Rasmus?For one, I would prefer to see 4.x but I'm not sure it is ready yet.
However 4.x also needs the changes applied to support recent
optimizations in the engine (they have been applied to trunk only). I
would suggest to do the merges prior to include it.
I had a bit of a chat with Gopal about this the other day. And he
reckoned it'd be smarter to go with the current trunk. Reasons he
mentioned that he has very little idea what went on in 4_0 and he feels
that 4_0 is turning APC sortof into memcache, with way too many complex
caching layers. I feel inclined to follow his advice... even more
because he's the lead dev :-)
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
I had a bit of a chat with Gopal about this the other day. And he
reckoned it'd be smarter to go with the current trunk. Reasons he
mentioned that he has very little idea what went on in 4_0 and he feels
that 4_0 is turning APC sortof into memcache, with way too many complex
caching layers.
This description is somehow not correct.
The idea of the 4.x branch is to allow more flexibility to the memory
layer in APC. Features like per site cache (think security here) or
more fine grained caching requires this redesign. That's something
critical for shared hosts (which is the reason why we should bundle an
opcode cache) as dedicated hosts can install it easily already.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
We may also want to include the signals patch as part of the commit,
as that both enhances speed and makes critical sections more safe,
which is pretty important for opcode caches such as PHP.
It seems like theres been enough votes for moving it to the core, is
there anyone willing to make that change? Rasmus or Derick? We can
always decide whether to enable it by default afterwards.I can do it; but the question is whether we want to use APC 3.x or 4.x
in trunk? Gopal, Rasmus?regards,
Derick--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
2010/6/22 Ilia Alshanetsky ilia@prohost.org:
We may also want to include the signals patch as part of the commit,
as that both enhances speed and makes critical sections more safe,
which is pretty important for opcode caches such as PHP.
Whats the status of the zend signal handling RFC/patch, did it need
Windows support or any other things? If so then I dont see a reason
not to include it as it is now, as it will be improved anyway as we
are getting closer to a release.
--
regards,
Kalle Sommer Nielsen
kalle@php.net
I believe it is a *nix specific patch.
2010/6/22 Ilia Alshanetsky ilia@prohost.org:
We may also want to include the signals patch as part of the commit,
as that both enhances speed and makes critical sections more safe,
which is pretty important for opcode caches such as PHP.Whats the status of the zend signal handling RFC/patch, did it need
Windows support or any other things? If so then I dont see a reason
not to include it as it is now, as it will be improved anyway as we
are getting closer to a release.--
regards,Kalle Sommer Nielsen
kalle@php.net
It should be included by default AND enabled by default AND all the
test suites should be run in that configuration. It seems crazy to me
to test against a configuration that no one is expected to run.
BTW: Can someone bump up the version of APC and do a release so some
more recent fixes find their way into distros? Thx.
I believe it is a *nix specific patch.
Yes, the patch is unix only. I don't think either it can be simply
'ported' to windows.
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
2010/6/23 Ilia Alshanetsky ilia@prohost.org:
I believe it is a *nix specific patch.
Looking over the patch, it uses some POSIX specific signals whereas
Windows only supports the ANSI ones. I don't know how much sense it
makes to enable the signal handling for ANSI-only compatible system.
Either way I think it should get committed and APC moved into trunk,
we seem to have enough votes for this.
--
regards,
Kalle Sommer Nielsen
kalle@php.net
Just a ping on this one, with the 3.1.4 release would anyone be in
favour of moving it into trunk now? If not, then I can do it with some
help from someone who have moved a pecl extension into core before.
--
regards,
Kalle Sommer Nielsen
kalle@php.net
hi,
It is still beta. But Gopal and Rasmus should decide when it is ready.
Just a ping on this one, with the 3.1.4 release would anyone be in
favour of moving it into trunk now? If not, then I can do it with some
help from someone who have moved a pecl extension into core before.--
regards,Kalle Sommer Nielsen
kalle@php.net--
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
hi,
Just a ping on this one, with the 3.1.4 release would anyone be in
favour of moving it into trunk now? If not, then I can do it with some
help from someone who have moved a pecl extension into core before.It is still beta. But Gopal and Rasmus should decide when it is ready.
Moving an extension from PECL to Core has side effects, like typically the PECL version dies. APC is not ready for that, so I don't think it's time. Well, I think many extensions should live in PECL and be bundled during the release process (instead of being moved into core at all) but that's another story....
Regards,
Philip
Moving an extension from PECL to Core has side effects, like
typically the PECL version dies.
Sadly, this is very true.
Well, I think many extensions should live in
PECL and be bundled during the release process (instead of being
moved into core at all) but that's another story....
This would really make sense!
I'd help out if we could get anywhere down that road.
Cheers,
Mike