Re: [PHP-DEV] APC in trunk
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. On Jun 21, 2010, at 9:31 AM, Sebastian Bergmann s...@sebastian-bergmann.de wrote: 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 BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
On 06/20/2010 10:21 PM, 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 on adding into the distro -1 on enabling by default -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
Ilia Alshanetsky wrote: The test was done on Windows... I never said it was IIS only, it is however win32 only. Sorry - Most people using it will no have bought win64 yet was the point and the test was done on win32 as far as I can tell. Anyway Pierre keeps saying that 64 bit is slower anyway ;) All extensions can be disabled by the user compiling the code... On Linux that is fine, but on Windows? We keep having this debate on what is compiled into windows builds and what is optional and that is the point here. Although the increase in third party sites providing more flexible windows builds is probably the way ahead. -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
On Jun 20, 2010, at 10:06 PM, Rasmus Lerdorf wrote: On 6/20/10 7:55 PM, Scott MacVicar wrote: On Jun 20, 2010, at 11:21 AM, 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 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
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 BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
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 BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
On 21.06.2010, at 05:32, Stas Malyshev wrote: 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 m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
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 BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
2010/6/21 Sebastian Bergmann s...@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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
Ilia Alshanetsky i...@prohost.org wrote in message news:aanlktilzlbbfucuv-jtmkm-qljl1il7wsqy0fyhn3...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
Rasmus Lerdorf ras...@lerdorf.com wrote in message news:4c1ed90d.2030...@lerdorf.com... On 6/20/10 7:44 PM, Stas Malyshev wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
hi, On Mon, Jun 21, 2010 at 10:58 AM, jvlad d...@yandex.ru wrote: Rasmus Lerdorf ras...@lerdorf.com wrote in message news:4c1ed90d.2030...@lerdorf.com... On 6/20/10 7:44 PM, Stas Malyshev wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
On Mon, Jun 21, 2010 at 11:31 AM, jvlad d...@yandex.ru wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
On Mon, Jun 21, 2010 at 11:55 AM, jvlad d...@yandex.ru wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
hi, On Mon, Jun 21, 2010 at 12:30 PM, jvlad d...@yandex.ru wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
On windows it is even easier, just don't load the dll file, most extensions other then PCRE (?) are compiled as modules anyway... APC would be no different, and I would go as far as saying that on Win32 Wincache is probably a better choice. On Mon, Jun 21, 2010 at 2:15 AM, Lester Caine les...@lsces.co.uk wrote: Ilia Alshanetsky wrote: The test was done on Windows... I never said it was IIS only, it is however win32 only. Sorry - Most people using it will no have bought win64 yet was the point and the test was done on win32 as far as I can tell. Anyway Pierre keeps saying that 64 bit is slower anyway ;) All extensions can be disabled by the user compiling the code... On Linux that is fine, but on Windows? We keep having this debate on what is compiled into windows builds and what is optional and that is the point here. Although the increase in third party sites providing more flexible windows builds is probably the way ahead. -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
Same here. +1 to bundle -1 to enable it by default On 21 Jun 2010 13:05, Rob Richards rricha...@php.net wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub...
Re: [PHP-DEV] APC in trunk
On 21.06.2010, at 13:07, jvlad wrote: 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 m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
On 19 June 2010 14:23, Kalle Sommer Nielsen ka...@php.net wrote: 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=ZEND002498r=213474731 ZOPA : http://uk.zopa.com/member/RQuadling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
Ilia Alshanetsky wrote: On windows it is even easier, just don't load the dll file, most extensions other then PCRE (?) are compiled as modules anyway... APC would be no different, and I would go as far as saying that on Win32 Wincache is probably a better choice. As long as these are added as loadable extensions then that is not a problem. The windows builds do bundle some things RATHER than adding everything as extensions, and it is that which I am probably flagging up. So as long as I can pick and choise which extensions are shipped with a windows build I'm happy. If it IS an extension that can be left out, then it should not be enabled by default anyway? -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
On Sun, Jun 20, 2010 at 11:39:30PM -0400, Ilia Alshanetsky wrote: 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 LNG way in showing others that APC is a serious codebase again. -- === Jim Jagielski [|] j...@jagunet.com [|] http://www.jaguNET.com/ Great is the guilt of an unnecessary war ~ John Adams -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
On 06/21/2010 04:32 PM, Jim Jagielski wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
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 On Jun 21, 2010, at 5:50 AM, Antony Dovgal t...@daylessday.org wrote: On 06/21/2010 04:32 PM, Jim Jagielski wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
On Jun 21, 2010, at 10:02 PM, Zeev Suraski wrote: 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. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
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 Sat, Jun 19, 2010 at 9:23 AM, Kalle Sommer Nielsen ka...@php.net wrote: 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 ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
( 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
On 20.06.2010, at 22:21, Lester Caine 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? 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 m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
+1 as Lukas, on adding but not enabled by default. On Jun 20, 2010, at 4:39 PM, Lukas Kahwe Smith m...@pooteeweet.org wrote: On 20.06.2010, at 22:21, Lester Caine 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? 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 m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
On 6/20/10 1:21 PM, Lester Caine 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. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
On Sun, 20 Jun 2010, Rasmus Lerdorf wrote: On 6/20/10 1:21 PM, Lester Caine 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. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
On Sun, Jun 20, 2010 at 10:39 PM, Lukas Kahwe Smith m...@pooteeweet.orgwrote: On 20.06.2010, at 22:21, Lester Caine 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? 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
Re: [PHP-DEV] APC in trunk
On Sun, 20 Jun 2010, 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. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
Rasmus Lerdorf wrote: On 6/20/10 1:21 PM, Lester Caine 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
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 Jun 20, 2010, at 1:56 PM, Ferenc Kovacs i...@tyrael.hu wrote: On Sun, Jun 20, 2010 at 10:39 PM, Lukas Kahwe Smith m...@pooteeweet.orgwrote: On 20.06.2010, at 22:21, Lester Caine 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? 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
On 6/20/10 2:05 PM, Lester Caine wrote: Rasmus Lerdorf wrote: On 6/20/10 1:21 PM, Lester Caine 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
Rasmus Lerdorf wrote: On 6/20/10 2:05 PM, Lester Caine wrote: Rasmus Lerdorf wrote: On 6/20/10 1:21 PM, Lester Caine 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
hi, On Sun, Jun 20, 2010 at 11:32 PM, Lester Caine les...@lsces.co.uk wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
Sure, but that's win32 only Ilia Alshanetsky CIO/CSO Centah Inc. On 2010-06-20, at 16:54, Derick Rethans der...@php.net wrote: On Sun, 20 Jun 2010, Rasmus Lerdorf wrote: On 6/20/10 1:21 PM, Lester Caine 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. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
On 6/20/10 2:32 PM, Lester Caine wrote: Rasmus Lerdorf wrote: On 6/20/10 2:05 PM, Lester Caine wrote: Rasmus Lerdorf wrote: On 6/20/10 1:21 PM, Lester Caine 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
Ilia Alshanetsky i...@prohost.org wrote in message news:86a0c51a-e6f7-48f2-a065-eabe74c6a...@prohost.org... Several reasons: 1) APC is well maintained, by the same people who work on PHP. 2) The license does not preclude it's inclusion into the base version. 3) most people don't use any opcode cashes, which is not ideal when it comes to PHP. 4) 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
Hi 2010/6/21 Stas Malyshev smalys...@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 ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
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. On Sun, Jun 20, 2010 at 8:15 PM, jvlad d...@yandex.ru wrote: Ilia Alshanetsky i...@prohost.org wrote in message news:86a0c51a-e6f7-48f2-a065-eabe74c6a...@prohost.org... Several reasons: 1) APC is well maintained, by the same people who work on PHP. 2) The license does not preclude it's inclusion into the base version. 3) most people don't use any opcode cashes, which is not ideal when it comes to PHP. 4) 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
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. On Sun, Jun 20, 2010 at 10:44 PM, Stas Malyshev smalys...@sugarcrm.com wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
On 6/20/10 7:44 PM, Stas Malyshev wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
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. On Sun, Jun 20, 2010 at 11:19 PM, Stas Malyshev smalys...@sugarcrm.com wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
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. On Sun, Jun 20, 2010 at 11:31 PM, Stas Malyshev smalys...@sugarcrm.com wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
On Jun 20, 2010, at 11:21 AM, 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 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
On 6/20/10 7:55 PM, Scott MacVicar wrote: On Jun 20, 2010, at 11:21 AM, 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 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
