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.
