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 <te...@ellisons.org.uk
<mailto:te...@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.
