You posted this in two places, so I will add my answer here as well:

You are making a lot of assumptions here based on no evidence. The way opcode 
caches work, it's not like it creates a single op_array of an entire application 
and writes that. Each included file is turned into an op_array, so when you say 
an app has to load hundreds of files, this would be exactly the same if you had 
a file-based storage mechanism. The OS file cache would work exactly the same 
for php script files vs. op_array files, so no difference there. When I actually 
tested this with APC I saw less than a 5% speedup reading op_arrays from disk 
vs. simply re-compiling from the script. This is likely because we actually have 
to read more stuff in the compiled op_array case since it isn't just op_arrays 
stored. We also store function and object lists alongside so the savings you get 
from not having to recompile is eaten by the extra disk reads you need.

And yes, a memcache backend would suffer from the same fate assuming it is a 
standard distributed memcache setup. A local memcache instance with no network 
traffic might work, but I can't see that being available to many SuPHP users.

"You posted this in two places, so I will add my answer here as well:"

I didn't know which has more visibility. Apologies if this is a hassle. I'll reply here too, once again, but do let me know which one I should stick to if required.


"this would be exactly the same if you had a file-based storage mechanism"

Indeed, and I mentioned that as well. However, the OS would cache those files after the first hit, so after that point you should see great benefits as you're effectively reading from RAM ... granted, until that portion of OS file cache is overridden.

So on average, this should have visible advantages.

If however you always read from disk, i.e. OS does not cache the files, then yes, the advantages are not great, but it's unlikely for the OS not to cache them and get at least a few OS file-cache hits (i.e. RAM) before they get wiped, especially on busy websites.

p.s. I no longer have the evidence, but I did mention I saw big improvements a long time ago when eAccelerator also had a file-based storage engine.

Opcache in PHP 7 supports a file cache. I don't know whether the way it is currently managed is compatible with SuPHP.

Interested in that as well. 
Can someone tell, will the PHP 7 features regarding file cache be backported to 5.6 branch and PECL or not please?

> Opcache in PHP 7 supports a file cache.

Indeed, see the opcache.file_cache* ini directives:
<http://php.net/manual/en/opcache.configuration.php>

> I don't know whether the way it is currently managed is
> compatible with SuPHP.

Me neither, but I'm closing this FR nonetheless. Feel free to
re-open if it doesn't work with SuPHP.

> […] will the PHP 7 features regarding file cache be backported
> to 5.6 branch and PECL or not […]

Most likely they will not be backported to PHP 5.6, and almost
certainly not to PECL/APC which appears to be unmaintained anyway.