We haven't done anything about making APC work for CGI for two main reasons.
1. If you are using a fork-per-request CGI model you are obviously not
that concerned about performance. Dedicated VM hosting prices have
dropped dramatically in the past couple of years, so it is within reach
of just about anyone to get a decent setup.
As I said: If you don't have high traffic or some income through the site you manage, then you don't want to spend USD 20 or more per month. Cheap virtual servers often just give you the illusion to get a great product and be your own root, but you are in fact sharing so much resources with other VMs and typically only few MB of RAM, that a shared hosting environment might be faster and more optimized.
Of course you can't get a fastest setup with a shared hosting plan, but users definetely notice whether a Joomla website with some extra menus and modules takes 2 seconds to load or just 0.5s, even if you could maybe get it to 0.1s with mod_ph and APC.
2. We point the executor directly at the op_array in locally mapped
shared memory. We also have top-level function and class caches for each
op_array in shared memory with the opcodes to create these NOP'ed away.
If we were to read an op_array from something like memcache we wouldn't
be able to do any of this. We would do extremely well to just match the
performance of simply re-parsing from disk with having to connect, copy,
munge and execute these from a remote source on every request. Plus you
have added latency in actually caching these to a slower storage
mechanism along with the stat check overhead on each request.
I know that APC can do a lot more than keeping opcode in memory, but would it be so hard to make it work similar to the Java JSP style in its simplest case (=CGI mode)? Each .jsp file gets compiled to a class and the bytecode is only re-generated (ie. the class-recompiled) when the original .jsp file has changed. Couldn't APC precompile the PHP-files to a .cache-folder or similar if not even in memcached?
Kind regards
Marten