Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:56772 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 97333 invoked from network); 4 Dec 2011 19:55:32 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Dec 2011 19:55:32 -0000 Authentication-Results: pb1.pair.com smtp.mail=tom@punkave.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=tom@punkave.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain punkave.com designates 209.85.216.170 as permitted sender) X-PHP-List-Original-Sender: tom@punkave.com X-Host-Fingerprint: 209.85.216.170 mail-qy0-f170.google.com Received: from [209.85.216.170] ([209.85.216.170:38610] helo=mail-qy0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 37/75-65129-330DBDE4 for ; Sun, 04 Dec 2011 14:55:32 -0500 Received: by qcsc1 with SMTP id c1so1141478qcs.29 for ; Sun, 04 Dec 2011 11:55:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.175.2 with SMTP id v2mr5426133qaz.69.1323028529028; Sun, 04 Dec 2011 11:55:29 -0800 (PST) Received: by 10.224.105.147 with HTTP; Sun, 4 Dec 2011 11:55:29 -0800 (PST) In-Reply-To: References: <012201ccb1d5$356a6fa0$a03f4ee0$@alliantinternet.com> <012601ccb1e9$6b7aad80$42700880$@alliantinternet.com> <4EDA6E8C.6040105@lerdorf.com> Date: Sun, 4 Dec 2011 14:55:29 -0500 Message-ID: To: PHP Internals Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [PHP-DEV] Will apc.optimization ever be put back to APC? From: tom@punkave.com (Tom Boutell) I see your point about optimization being time consuming and the penalty being greater if you're not using a bytecode cache. But that's a reason to make it optional, not a reason to couple it with a specific bytecode cache so it can't be used with others. As for optimization not accomplishing all that much in PHP in general, that I can't really argue with if it's true (: On Sun, Dec 4, 2011 at 12:10 PM, Graham Kelly wrote: > While it might seem like a good idea to put something like this into > APC it really just creates more problems than it is worth. I belive it > was removed for that very reason; because it was making it difficult > to distinguish opcode cache errors from optimizer errors. > > There was an attempt to move this out of APC and into a pecl/optimizer > extension but that never panned out. Additionally, the optimizations > never yielded anything too substantial.The problem is that while you > might be able to optimize away several opcodes you are still left with > the general overhead incurred from running PHP which prevents you from > getting too much further. Some of the optimizations have been moved > into PHP 5.3 (constant folding) and PHP 5.4 but many of them still > have not been (dead code elimination, various jump optimizations etc > etc). > > The assumption that it would be better to move an optimization pass > into PHP core so that all programs, even those not using an opcode > cache, could benefit from them isnt holy accurate. Optimization takes > time. A prime example of this is the fact that optimization comprises > the majority of the time spent by most C compilers. Without an opcode > cache it is very possible that the amount of time spent to optimize a > section of code could be longer than the amount of time/memory saved > by it. > > Ultimately, advances will continue to be made in terms of PHP > performance. But, those will probably not happen in opcode caches and > might not happen in optimizer specific extensions. > > On Sat, Dec 3, 2011 at 1:46 PM, Rasmus Lerdorf wrote: >> On 12/03/2011 10:28 AM, Dmitri Snytkine wrote: >>> APC is great, APC definetely speeds up the php a lot but I just remember that there used to be also optimization options. >>> I remember the days where eAccelerator and php accelerator and mmcache were popular. They all had code optimization option to speed up compiled scripts. >> >> Many of those optimizations have been either rolled into the standard >> compiler or made irrelevant by changes to the opcodes themselves. >> >> -Rasmus >> >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com