Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:50080 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 99695 invoked from network); 2 Nov 2010 16:13:43 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 Nov 2010 16:13:43 -0000 Authentication-Results: pb1.pair.com smtp.mail=ar@ez.no; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=ar@ez.no; sender-id=unknown Received-SPF: error (pb1.pair.com: domain ez.no from 74.125.82.170 cause and error) X-PHP-List-Original-Sender: ar@ez.no X-Host-Fingerprint: 74.125.82.170 mail-wy0-f170.google.com Received: from [74.125.82.170] ([74.125.82.170:56087] helo=mail-wy0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 39/80-31785-4B830DC4 for ; Tue, 02 Nov 2010 11:13:42 -0500 Received: by wyb35 with SMTP id 35so7253651wyb.29 for ; Tue, 02 Nov 2010 09:13:38 -0700 (PDT) Received: by 10.227.153.14 with SMTP id i14mr11874486wbw.142.1288714417383; Tue, 02 Nov 2010 09:13:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.145.133 with HTTP; Tue, 2 Nov 2010 09:13:17 -0700 (PDT) In-Reply-To: <4CCFD28B.7070901@lsces.co.uk> References: <4CCFD28B.7070901@lsces.co.uk> Date: Tue, 2 Nov 2010 17:13:17 +0100 Message-ID: To: Lester Caine Cc: PHP internals Content-Type: multipart/alternative; boundary=0016363b9f8210a85b0494143574 Subject: Re: [PHP-DEV] PHP 5.4: Adding APC From: ar@ez.no (=?UTF-8?B?QW5kcsOpIFLDuG1ja2U=?=) --0016363b9f8210a85b0494143574 Content-Type: text/plain; charset=UTF-8 On Tue, Nov 2, 2010 at 9:57 AM, Lester Caine wrote: > Derick Rethans wrote: > >> Actually, Kalle just pointed out that it compiles just fine. In that >> case, I think we should put it in trunk and in the 5.4 alpha. >> > > As long as it is disabled by default and can easily be replaced by > preferred alternatives ... eaccelerator is still working fine now that it > has been upgraded to handle 5.3 ... although it would be nice to see some > more up to date comparisons. Although I suspect in reality, the combination > with database and other caching activity means that a straight comparison > may be a little meaningless? Change the database and the figures are going > to be different anyway ... so a straight comparison on non-database code > would be a little more practical. > +1. Being disabled by default was agreed on for "old 6.x" so should be for 5.4 as well. However I think there probably is a lot of possibilities for PHP if it was better integrated in the future (lets say "new 6.x"). To offer better autoload performance if you stick to PSR-0 for class autoloading for instance. Hence a future php version that has better persistent knowledge of classes used on the system so every class load doesn't result in a full require call with all its overhead on every request. And/Or a shared api / backend for shared persistent cache for stat calls, real path and parsed php structures, and anything else one might want to let persist between requests in the future. A discussion for another thread some other time off course. > -- > Lester Caine - G8HFL > ----------------------------- > Contact - http://lsces.co.uk/wiki/?page=contact > L.S.Caine Electronic Services - http://lsces.co.uk > EnquirySolve - http://enquirysolve.com/ > Model Engineers Digital Workshop - http://medw.co.uk// > Firebird - http://www.firebirdsql.org/index.php > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > --0016363b9f8210a85b0494143574--