Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67326
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain zend.com from 209.85.220.181 cause and error)
MIME-Version: 1.0
In-Reply-To: <51850D2B.80902@ellisons.org.uk>
References: <51850D2B.80902@ellisons.org.uk>
Date: Tue, 7 May 2013 17:14:01 +0400
Message-ID: <CA+9eiLsOHrUR_nuUTh3MHwsWVfhufbHNhhbeRwMDF-LqfmBK6w@mail.gmail.com>
To: Terry Ellison <Terry@ellisons.org.uk>
Cc: pecl-dev-@lists.php.net, 
	"internals@lists.php.net" <internals@lists.php.net>, Andi Gutmans <andi@zend.com>, 
	Stanislav Malyshev <stas@zend.com>, Zeev Suraski <zeev@zend.com>, Brendon Colby <brendon@newgrounds.com>, 
	Christopher Jones <christopher.jones@oracle.com>, Marten Lehmann <lehmann@cnm.de>
Content-Type: multipart/alternative; boundary=089e0115f69846bdec04dc209714
Subject: Re: Multi-level Caching Fork of OPcache -- update
From: dmitry@zend.com (Dmitry Stogov)

--089e0115f69846bdec04dc209714
Content-Type: text/plain; charset=UTF-8

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.
>
>

--089e0115f69846bdec04dc209714--