Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65692
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain ellisons.org.uk from 79.170.44.47 cause and error)
Message-ID: <511256DE.4090004@ellisons.org.uk>
Date: Wed, 06 Feb 2013 13:13:02 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative;
 boundary="------------070107040008090706030809"
Subject: A quick intro for Terry Ellison and my extension work
From: Terry@ellisons.org.uk (Terry Ellison)

--------------070107040008090706030809
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I've posted a few times to this list and may do so some more, so as a 
courtesy I though that I should give a short intro on me and what I am 
doing here.  By way of a personal background, I retired early from HP 
five years ago due to ill-health though I have since recovered.  I was a 
Distinguished SE for what that was worth, and have been programming 
C/C++ and PHP for a LONG time.  Now I am a gentleman of leisure (AKA old 
fart) and now do it for pleasure only.

One thing about PHP that has always puzzled me was that we've never 
developed a good opcode caching solution for CGI and CLI use as the 
various opcode caches are add-on extensions rather than PHP core and 
really targeted for high-volume single UID environments.  I see two main 
problems with this:

1.  Multi-account service providers must employ UID based mandatory 
separation of processes, and no other shared approach meets even minimal 
security requirements.

2.  Whilst opcode caching only applies and an option for some PHP 
runtime environments and not all, it is not properly architected into 
the PHP compile and run environment, and hence the opcode caches -- by 
necessity -- seem to include quite a few clumsy workarounds to be able 
to run.  Opcode caching or at least a clear interface to such caches 
should be a PHP core feature for all execution modes.

What I've been doing for the last six months is to develop a Lightweight 
Program Cache (LPC) extension optimised for CGI and CLI use to get a 
better understanding of the problems and possible approaches to address 
these.  LPC started life as a fork of APC, but has turned into a 
stripped-down rewrite.  I see this primarily as a demonstrator and a 
vehicle for my really getting to grips with the internals of the PHP 
compiler and execution engine.  If anyone is interest or wants to get an 
overview of how PHP code caches work have a read of:

https://github.com/TerryE/php-extensions/blob/master/lpc/TECHNOTES.txt

I doubt that it will ever be anything more than beta code so I don't 
need a VCS account or any other karmas.  Nonetheless it does essentially 
work -- it roughly doubles the throughput of MediaWiki with no memory 
leaks.  However, it is a long way away from being at a level where I 
would suggest anyone pull the repository and plays with it.  I am still 
at Zend 2.3 and I need still need to roll in the extra 2.4 functional 
changes.  It fails the PHP test suite for some extensions, and I am 
currently tracking down a bunch of issues from the php5/Zend/test 
failures (yup -- one advantage of running in CLI mode is that I can test 
the extension against the entire PHP test suite in two passes -- one to 
build the per-script caches and a repeat to run against the cache version).

Anyway, regards to you all, Terry Ellison

--------------070107040008090706030809--