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
