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.te...@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) >
