Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67372
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain ellisons.org.uk from 79.170.44.47 cause and error)
Message-ID: <518A7C6A.2080504@ellisons.org.uk>
Date: Wed, 08 May 2013 19:25:14 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5
MIME-Version: 1.0
To: Dmitry Stogov <dmitry@zend.com>
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>
References: <51850D2B.80902@ellisons.org.uk> <CA+9eiLsOHrUR_nuUTh3MHwsWVfhufbHNhhbeRwMDF-LqfmBK6w@mail.gmail.com>
In-Reply-To: <CA+9eiLsOHrUR_nuUTh3MHwsWVfhufbHNhhbeRwMDF-LqfmBK6w@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------020607070706070909000700"
Subject: Re: Multi-level Caching Fork of OPcache -- update
From: Terry@ellisons.org.uk (Terry Ellison)

--------------020607070706070909000700
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Dmitry,
> 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.

Hi and thanks for this.  I won't have the full functionality in place 
for another month or so, though my pushes to my github repository should 
be fully functional on the main path and subject to caveats in the TODO, 
etc., so it's just more general guidance when you get time, e.g I would 
be happier if you approached X this way, or don't forget to address 
issue Y which we've been burnt on in the past...

Also have a scan through the wiki pages for B/G design info.  If you 
guys want, I could also do the equivalent for standard OPcache down the 
line, since I know have a pretty intimate knowledge of how it works; I 
would just need to know the target audience that you would like to address.

Regards
Terry
>
>
> On Sat, May 4, 2013 at 5:29 PM, Terry Ellison <Terry@ellisons.org.uk 
> <mailto: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 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.
>
>


--------------020607070706070909000700--