Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67297
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: <51850D2B.80902@ellisons.org.uk>
Date: Sat, 04 May 2013 16:29:15 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5
MIME-Version: 1.0
To: pecl-dev-@lists.php.net
CC: "internals@lists.php.net" <internals@lists.php.net>, 
 Andi Gutmans <andi@zend.com>,
 Stanislav Malyshev <stas@zend.com>, Dmitry Stogov <dmitry@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: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Multi-level Caching Fork of OPcache -- update
From: Terry@ellisons.org.uk (Terry Ellison)

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.