Re: Multi-level Caching Fork of OPcache -- update

Hi Terry, I don't have time right now (on this week), but I'll definitely take a look into your patch later. Thanks. Dmitry. On Sat, May 4, 2013 at 5:29 PM, Terry Ellison <Terry@ellisons.org.uk> wrote: > 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 > <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<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<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. > >