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)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
