Multi-level Caching Fork of OPcache -- update

Please treat this email by way of request for feedback from the OPcache developers and anyone interested in influencing my next steps on my https://github.com/TerryE/opcache fork of OPcache and specifically on the dev-filecache branch. The most appropriate channel is probably https://github.com/TerryE/opcache/issues -- unless you think that the comments have wider applicability for either the PECL or DEV communities. My ultimate aim is to take this to a point where the OPcache developers feel sufficiently comfortable to consider merging a future version back into OPcache. I have added some detailed project wiki pages documenting my scope and progress and in particular on https://github.com/TerryE/opcache/wiki/MLC-OPcache-details and a brief quote from the page:

An indication of the potential performance benefits of OPcache CLI mode can be seen from a simple benchmark based on 100 executions of the MediaWiki runJobs.php maintenance batch script. This compiles some 44 PHP sources, comprising 45K lines and 1,312 Kbytes. The cached version reads a single runJobs.cache file of 1,013 Kbytes.

 Time in mSec         Average  Stdev
 Uncached Execution     179      7
 Cached Execution        77      7
 (Image Load Overhead)   18      3

In other words for this script, the MLC cache is delivering an approximate 60% runtime saving. Of course this is only a point test, and benefits will vary -- though I hope that switching to LZ4 compression will improve these figures further. But even this one point challenges what seems to be a core PHP development dogma: "there's no point in using a file cache, because it makes no material performance difference". Even this build *does* deliver material benefits , and I suggest that there is merit in moving to including MLC cached modes to accelerate CLI and GCI SAPI modes using this or a similar approach. From an internals -- rather than PECL -- viewpoint what this would mean is that non-cached incremental compile-and-go execution modes would now be the exception than the norm -- largely negating the disadvantages of any compile-intensive optimization options. So thank-you in anticipation for your feedback. I will do my utmost to respond constructively to all comments. :-) Regards Terry Ellison PS. Apologies in advance: I am "up country" at my cottage on an Island in the north Aegean with the nearest Wifi some walk away, so my Internet access is limited at the moment, and I might take some time to respond.