lighttpd forum XCache > XCache and autoload

I'm trying to understand opcode caching in PHP, particularly as related 
to the use of __autoload.

In APC, I just found out that, according to Rasmus, autoloaded classes 
are not opcode cached. Given that it was Rasmus making this statement, 
there didn't seem much point in arguing. Someone said XCache didn't have 
this problem, so I installed it. I see most or all of my non-autoloaded 
classes cached, but none of the autoloaded ones, so XCache seems to work 
like APC.

I'd like to know more about the theory of operation of opcode caches. 
Does anyone know of any good references or is this knowledge just stored 
in the heads of the PHP pros?

With regards to autoload, what problems does it present to the caching 
code? Could any of  these problems be solved by tweaking the code or by 
giving the opcode cacher some additional information? If I have a 
conditional include, does that present the same problem? If I do a 
straight include but from a filtered PHP stream instead of a file, is 
that also a problem?

I'm seeing growing popularity for autoload and only a few mentions about 
its problems with opcode caching.

Thanks for any help.

Tony Freixa wrote:
> I'm trying to understand opcode caching in PHP, particularly as related 
> to the use of __autoload.
> 
> In APC, I just found out that, according to Rasmus, autoloaded classes 
> are not opcode cached. Given that it was Rasmus making this statement, 
> there didn't seem much point in arguing. Someone said XCache didn't have 
> this problem, so I installed it. I see most or all of my non-autoloaded 
> classes cached, but none of the autoloaded ones, so XCache seems to work 
> like APC.
i'll try to reproduce it.
> 
> I'd like to know more about the theory of operation of opcode caches. 
> Does anyone know of any good references or is this knowledge just stored 
> in the heads of the PHP pros?
yep, just store opcode it in memory
> 
> With regards to autoload, what problems does it present to the caching 
> code? Could any of  these problems be solved by tweaking the code or by 
> giving the opcode cacher some additional information? If I have a 
> conditional include, does that present the same problem? If I do a 
> straight include but from a filtered PHP stream instead of a file, is 
> that also a problem?
user defined stream is not supported yet in XCache but we may look into 
it if it's useful for most users who also need performance.
> 
> I'm seeing growing popularity for autoload and only a few mentions about 
> its problems with opcode caching.
> 
> Thanks for any help.

moo XCache wrote:
> Tony Freixas wrote:
>> I'm trying to understand opcode caching in PHP, particularly as related 
>> to the use of __autoload.
>> 
>> In APC, I just found out that, according to Rasmus, autoloaded classes 
>> are not opcode cached. Given that it was Rasmus making this statement, 
>> there didn't seem much point in arguing. Someone said XCache didn't have 
>> this problem, so I installed it. I see most or all of my non-autoloaded 
>> classes cached, but none of the autoloaded ones, so XCache seems to work 
>> like APC.
> i'll try to reproduce it.

Actually, don't bother. My autoloaded classes are also all input from a 
PHP input stream, which you state below you don't support.

After I posted this message, I did a Google search using  the term 
"theory of operation PHP opcode caching". I found a lot more information 
on opcode caching, including a follow-up by Rasmus on his earlier 
statement. He said autoload wasn't the problem, it was conditional 
classes resulting from conditional includes. To be honest, I didn't 
understand his answer, but I did understand that autoload by itself is 
not a problem.

>> I'd like to know more about the theory of operation of opcode caches. 
>> Does anyone know of any good references or is this knowledge just stored 
>> in the heads of the PHP pros?
> yep, just store opcode it in memory

Lovely. It's not a big issue for XCache, which sounds like a one-person 
volunteer project. I'll see if I can get some action from APC, as there 
is a proposal to make it part of PHP 6.

>> With regards to autoload, what problems does it present to the caching 
>> code? Could any of  these problems be solved by tweaking the code or by 
>> giving the opcode cacher some additional information? If I have a 
>> conditional include, does that present the same problem? If I do a 
>> straight include but from a filtered PHP stream instead of a file, is 
>> that also a problem?
> user defined stream is not supported yet in XCache but we may look into 
> it if it's useful for most users who also need performance.

Of course, it's a bit of a chicken-and-egg problem. If the opcode caches 
don't support input filters for includes/requires, then you can bet the 
users who need performance won't use input filters.

The advantage of input filters is the ability to create a dynamic 
pre-processing library for PHP code. In theory, you could write a filter 
that would use the C pre-processor or the m4 macro processor to 
pre-process the code. The disadvantage is the overhead of running the 
code through the input filter. If the opcode cache could read the the 
filtered code, the overhead disappears and the door opens to a ton of 
enhancements.

Tony Freixas wrote:
> Actually, don't bother. My autoloaded classes are also all input from a 
> PHP input stream, which you state below you don't support.
> 
> After I posted this message, I did a Google search using  the term 
> "theory of operation PHP opcode caching". I found a lot more information 
> on opcode caching, including a follow-up by Rasmus on his earlier 
> statement. He said autoload wasn't the problem, it was conditional 
> classes resulting from conditional includes. To be honest, I didn't 
> understand his answer, but I did understand that autoload by itself is 
> not a problem.
maybe he's talking about
a.php:
if (defined('a')) return 0;
define('a');

class a
{
}

or two different "class a in a1.php/a2.php" while "class b extends a" in 
b.php

if ($use_a1) {
 include "a1.php";
}
else {
 include "a2.php";
}
class b extends a
{
...
}


this is not a problem in XCache

> Lovely. It's not a big issue for XCache, which sounds like a one-person 
> volunteer project. I'll see if I can get some action from APC, as there 
more volunteers are welcome to join this project, but none yet :(
> is a proposal to make it part of PHP 6.
XCache support unicode  already :)
works great with php6 and support PER_DIR (if php gonna support it this 
way) unicode.semantics instead of just INI_SYSTEM wide

> Of course, it's a bit of a chicken-and-egg problem. If the opcode caches 
> don't support input filters for includes/requires, then you can bet the 
> users who need performance won't use input filters.
> 
> The advantage of input filters is the ability to create a dynamic 
> pre-processing library for PHP code. In theory, you could write a filter 
> that would use the C pre-processor or the m4 macro processor to 
> pre-process the code. The disadvantage is the overhead of running the 
> code through the input filter. If the opcode cache could read the the 
> filtered code, the overhead disappears and the door opens to a ton of 
> enhancements.

it's doable, but is a bit more complex than filesystem.
it depends on how user define "dynamic" semantics in php
 does it support stat?
  yes, use stat
  no
    "url a == content a" is true all the time?
    yes, $cache[$url] = compile(file_get_content($url));
    no, $php = file_get_content($url); $cache[$php] = compile($php);

moo XCache wrote:
> it's doable, but is a bit more complex than filesystem.
> it depends on how user define "dynamic" semantics in php
>  does it support stat?
>   yes, use stat
>   no
>     "url a == content a" is true all the time?
>     yes, $cache[$url] = compile(file_get_content($url));
>     no, $php = file_get_content($url); $cache[$php] = compile($php);

Hey, thanks for all the details!

I don't understand your second yes/no options. The code looks like it 
does exactly the same in both cases.

As far as input streams, I think the user, not the opcode cache writer, 
needs to assume responsibility for when the code needs to be re-cached. 
After all, I could write a filter where the code generated varies 
depending on the time of day.

I think XCache provides all the tools one needs to force a re-cache 
through the admin screen. I assume there's an API the admin screen uses. 
For my code, I would add some bootstrap code to check for changes to the 
file containing the input filter. If it changes, I would remove all 
modules that are input through the input filter from the cache (or just 
clear the whole cache).

So I think all XCache needs to do is:

if supports stat then
  use current code;
else
  $cache[$url] = compile(file_get_contents($url));

The rest is the user's problem.

> I don't understand your second yes/no options. The code looks like it 
> does exactly the same in both cases.
it depends if we can assume that input stream/filter is determined. 
which mean for $content = filter($url), if $url is the same, filter 
returns the same $content always.

> if supports stat then
>   use current code;
> else
>   $cache[$url] = compile(file_get_contents($url));
> 
> The rest is the user's problem.

maybe we can just have an option for user like 
xcache.enable_userstream_caching

moo XCache wrote:

> maybe we can just have an option for user like 
> xcache.enable_userstream_caching

That would be perfect!