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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
