Re: Multi-level Caching Fork of OPcache -- update

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.