The file itself can be cached but its cached as a seperate entity, to be included on demand, it is not cached as a "part" of your main code.
What this means is instead of ending up with a single large opcache compiled version you end up with a smaller main "block" and all your autoloaded blocks. Depending on the size of your blocks you may or may not see a diffrence, Larger blocks will see an increase, but for a lot of small blocks its possible to see no increase or even a decrease in performance.. Again this is just based on what people like Rasmus have said, Some good benchmarks will be needed to really see the whole picture. On 1/9/07, Laurent TAUPIAC <[EMAIL PROTECTED]> wrote:
When i look in my APC system cache entry, i can see that every php (main or included) is cached. So when file is loaded, it is compile, then op-code is saved. Next time, it ll be loaded from cache. May be all entry will not be generated the first time, but that s the same if you are doing include under condition. If you load a file from include or from an autoload function (it will be an include too at the end), the only diff is an intern php event thrown when a reference is done to an unknown class, then autoload function is called. If autoload function try to load a class definition already present in APC cache, there is no compile phase (unless cache expired). Once every file has been compile and put in apc cache, there is no new compile phase until cache entry expired. Shekar C Reddy a écrit : What we need is a conclusive clarification on various op-caches and their behaviors. On 1/9/07, Shekar C Reddy <[EMAIL PROTECTED]> wrote: > > Again, the following statement from Rasmus contradicts with the statement made by Lars above (using XCache) who says, "You can see cached files in the stats which are just loaded via autoload": > > > It boils down to the fact that anything you push down into the executor is going > > to be slower than the same thing done in the compile phase. > > This is not an APC-specific thing, but a generic characteristic of any cache > > that caches the output of the compile phase. > > > > > On 1/9/07, Richard Thomas <[EMAIL PROTECTED] > wrote: > > Check out some of the discussions you will find here > > http://www.google.com/search?hl=en&lr=&q=autoload+opcache&btnG=Search > > > > Specific place to look is http://news.php.net/php.apc.dev/9 > > > > Also bug report > > > > http://pecl.php.net/bugs/bug.php?id=8765 > > > > A comment that sticks out > > > > "Using __autoload and require_once basically destroys any advantage apc > > is likely to bring you. Mainly because you move the compilation sequence > > into mid-runtime land, where the engine stops execution and proceeds to > > compile stuff. " > > > > Although from what I here the require_once issue has been solved with php 5.2 > > > > > > > > On 1/9/07, Lee Saferite < [EMAIL PROTECTED]> wrote: > > > Richard, > > > > > > Not to doubt your statements, but that seems like the most brain dead design > > > you could have. > > > I'm not savvy on the internals of the Zend Engine and OpCode Caches, but why > > > wouldn't they be able to cache the classes? Seems like a natural thing to > > > do to me. As for cool and fun, I personally find the idea of autoloading > > > the better way of doing it. When you start having external dependencies in > > > your classes, the chain-reaction loading of files can kill you. Especially > > > when you do not need all the loaded files. Anyway, could you provide some > > > relevant links about the opcache problems. I've seen lots of people say the > > > same thing, but never any real proof. > > > > > > Thanks, > > > Lee > > > > > > > > > On 1/9/07, Richard Thomas < [EMAIL PROTECTED]> wrote: > > > > Ok, so here is the thing, while autoloading might be cool and fun it > > > > doesn't work with OpCaches... > > > > > > > > Let me rephrase that, Your code will work but you will not see the > > > > full use of the opcache, this has been discussed in detail on the pear > > > > mailing lists and a couple other places. > > > > > > > > Basically when you load any file using a variable as the target an > > > > opcache can not cache that file fully because it has no idea or not if > > > > the next request is going to be the same file. > > > > > > > > If you want to take full advantage of opcaches from my understanding > > > > of the discussion you have to do > > > > > > > > require('pathtofile'); OR > > > require(CONSTANT_BASE_PATH.'restofpath'); > > > > > > > > If any non constant value is used an opcache will not cache fully, If > > > > your "constant" can change each page load you might run into errors. > > > > > > > > > > > > Now granted this is just what I gather from the stuff I have read over > > > > the last 2 months, I trying to put together a good benchmark to see > > > > whats the story is IRL. > > > > > > > > > > > > > > -- --------------------------------------------------------------------- Sorry, This disclamer is auto added by FW's company --------------------------------------------------------------------- Si vous n'etes pas destinataires de ce message, merci d'avertir l'expediteur de l'erreur de distribution et de le detruire immediatement. Ce message contient des informations confidentielles ou appartenant a La Francaise des Jeux. Il est etabli a l'intention exclusive de ses destinataires. Toute divulgation, utilisation, diffusion ou reproduction (totale ou partielle) de ce message ou des informations qu'il contient, doit etre prealablement autorisee. Tout message electronique est susceptible d'alteration et son integrite ne peut etre assuree. La Francaise des Jeux decline toute responsabilite au titre de ce message s'il a ete modifie ou falsifie. If you are not the intended recipient of this e-mail, please notify the sender of the wrong delivery and delete it immediately from your system. This e-mail contains confidential information or information belonging to La Francaise des Jeux and is intended solely for the addressees. The unauthorised disclosure, use, dissemination or copying (either whole or partial) of this e-mail, or any information it contains, is prohibited. E-mails are susceptible to alteration and their integrity cannot be guaranteed. La Francaise des Jeux shall not be liable for this e-mail if modified or falsified.
