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 <[email protected]> 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.
>
>
Thread (3 messages)