Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:46692 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 73314 invoked from network); 13 Jan 2010 15:31:26 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 13 Jan 2010 15:31:26 -0000 Authentication-Results: pb1.pair.com header.from=addw@phcomp.co.uk; sender-id=permerror Authentication-Results: pb1.pair.com smtp.mail=addw@phcomp.co.uk; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain phcomp.co.uk designates 78.32.209.33 as permitted sender) X-PHP-List-Original-Sender: addw@phcomp.co.uk X-Host-Fingerprint: 78.32.209.33 freshmint.phcomp.co.uk Linux 2.6 Received: from [78.32.209.33] ([78.32.209.33:60729] helo=mint.phcomp.co.uk) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id AB/F3-00773-A47ED4B4 for ; Wed, 13 Jan 2010 10:31:25 -0500 Received: from addw by mint.phcomp.co.uk with local (Exim 4.63) (envelope-from ) id 1NV5Bh-00005a-Hl; Wed, 13 Jan 2010 15:31:13 +0000 Date: Wed, 13 Jan 2010 15:31:13 +0000 To: Graham Kelly Cc: Dave Ingram , "mathieu.suen" , Sebastian Bergmann , internals@lists.php.net Message-ID: <20100113153113.GN3978@phcomp.co.uk> Mail-Followup-To: Graham Kelly , Dave Ingram , "mathieu.suen" , Sebastian Bergmann , internals@lists.php.net References: <4B4DABED.4060202@easyflirt.com> <4B4DBF40.5040801@easyflirt.com> <4B4DCFDA.6090206@dmi.me.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Organization: Parliament Hill Computers Ltd Subject: Re: [PHP-DEV] About optimization From: addw@phcomp.co.uk (Alain Williams) On Wed, Jan 13, 2010 at 10:25:01AM -0500, Graham Kelly wrote: > Hi, > > Optimizations such as 5+7 into 13 really don't get you much. ZEND_ADD (and > other basic opcodes) are not in any way a slow point in a program. And > unfortunately to be able to optimize these you would probably need to put in > an extra pass in the compiler which would probably just slow things down > (unless you have a LOT of these types of additions). > > As for the foo() example... This looks very simple however it is actually a > very hard problem that would most likely take far more time and resources to > solve in the compiler then it would to just leave it be. The problem here is > that you need to understand everywhere that $a is assigned a value and its > value is used. The problem becomes very hard in other functions that have > loops and other types of control structures. It really just ends up > becomming a fairly complex mess to solve. > > The same can be said about quite a few of the other optimizations you can > think of. On the surface they seem simple (and a few of them actually are) > but most of them are complex... largely do to some of the unique 'features' > of PHP. > > In any case, optimization in PHP is not a lost cause. The first thing you > should really do is be using an opcode cache such as APC. Other than that Unfortunately: APC does not work with PHP 5.3 -- I have a site where I would love to use it but I cannot. I use APC to great effect elsewhere. Can anyone say when APC will be fixed for PHP 5.3, what about it being ready for PHP 6 ? > there are some solutions being worked on. There is Zend Optimizer and there > is pecl/optimizer (which to warn you is probably far from being stable). > There are also a few efforts to compile PHP such as the PHC compiler. > > Overall though, more often than not PHP is not the bottleneck of your > program and thus optimization wont get you too much. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Past chairman of UKUUG: http://www.ukuug.org/ #include