Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67686
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.181 as permitted sender)
Message-ID: <51B6F847.7000004@gmail.com>
Date: Tue, 11 Jun 2013 11:13:27 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: Dmitry Stogov <dmitry@zend.com>
CC: "internals@lists.php.net" <internals@lists.php.net>, 
 Stas Malyshev <smalyshev@sugarcrm.com>,
 Zeev Suraski <zeev@zend.com>
References: <51850D2B.80902@ellisons.org.uk> <CA+9eiLsOHrUR_nuUTh3MHwsWVfhufbHNhhbeRwMDF-LqfmBK6w@mail.gmail.com> <51AE6ECB.209@ellisons.org.uk> <51AF669A.5010101@ellisons.org.uk> <CA+9eiLtS_+w-V+EFQCxkEKcvGMr8VQ1=xXWb+ERigyHZpn2k7A@mail.gmail.com>
In-Reply-To: <CA+9eiLtS_+w-V+EFQCxkEKcvGMr8VQ1=xXWb+ERigyHZpn2k7A@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: Multi-level Caching Fork of OPcache -- update
From: ellison.terry@gmail.com (Terry Ellison)

On 10/06/13 09:20, Dmitry Stogov wrote:
> Sorry for slow response.
> I'm very busy with other work and have no time for MLC OPcache review.
> I don't think we can include it into main tree before 5.5.0 release 
> anyway.
> But in general I think we may include your work in the future releases.
>
> Also, thanks for useful reports about problems you've found in OPcache :)
>
> Thanks. Dmitry.
>
Dmitry,

One useful side-effect of writing the MLC support is that I've really 
had to take apart the core OPcache code to understand how it works.  
It's probably the first in-depth review that this extension has had from 
someone _outside_ the Zend team, so its only to be expected that anyone 
doing this would find a few issues.

What I do think needs to be said it that I think that you guys have done 
a fantastic job here in this development.  9 times out of 10 when I've 
initially thought "why didn't they do it this way?" when digging into 
the code, I've dug down in and discovered that you already had, or had 
approached it a better way.  IMO, the whole OPcache approach is tighter 
and more sound than that of APC.  Take one example of this: the 2-pass 
algo for compiled scripts which enables the storage for a compiled 
script be to allocated as a single storage unit.  This has two major 
performance benefits at runtime:

1)  The memory allocator overheads of preparing scripts for execution 
(and deallocation at rundown) are reduced by more than an order of 
magnitude.
2)  The memory needed to execute the script is in a contiguous memory 
areas, and this gives improved hardware (as in L1/L2/L3) caching which 
passes through to a runtime performance improvement.

There are a couple of things that I would refactor if I had written 
OPcache.  (I'll raise a couple of issues on these to discuss what I mean 
in more depth.  and when the MLC work reaches a plateau if you think its 
worthwhile I can cut a couple of branches to show you a possible solution.)
A)  The SMA startup bootstrap is just messy and needs refactoring.
B)  The simple dead-and-rebirth method of refreshing caches isn't going 
to scale well on real systems.

Terry
(Note the new email addr that I am using for php.net work, as this one 
isn't being blocked by the php.net server)