Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68345
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain zend.com from 209.85.128.177 cause and error)
MIME-Version: 1.0
In-Reply-To: <51B6F847.7000004@gmail.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>
	<51B6F847.7000004@gmail.com>
Date: Wed, 31 Jul 2013 14:35:48 +0400
Message-ID: <CA+9eiLs0VpjzCHmosKTRXi-9K5_Q-kfSfrDvB74Z4N1B-_8K5w@mail.gmail.com>
To: Terry Ellison <ellison.terry@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>, Stas Malyshev <smalyshev@sugarcrm.com>, 
	Zeev Suraski <zeev@zend.com>
Content-Type: multipart/alternative; boundary=089e013cbfbef9446904e2cc4932
Subject: Re: [PHP-DEV] Re: Multi-level Caching Fork of OPcache -- update
From: dmitry@zend.com (Dmitry Stogov)

--089e013cbfbef9446904e2cc4932
Content-Type: text/plain; charset=UTF-8

I agree with both (A) and (B).

However (B) was done on purpose and has its advantages and disadvantages.
Anyway, I've opened https://github.com/zendtech/ZendOptimizerPlus/issues/118

C) file based opcode caching may be interesting as well

but all these requests are going to be a part of next major release (may be
in php-5.6)

Thanks. Dmitry.

Thanks. Dmitry.


On Tue, Jun 11, 2013 at 2:13 PM, Terry Ellison <ellison.terry@gmail.com>wrote:

> 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)
>

--089e013cbfbef9446904e2cc4932--