Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:56773 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 2967 invoked from network); 4 Dec 2011 20:46:26 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Dec 2011 20:46:26 -0000 Authentication-Results: pb1.pair.com header.from=devis@oracolo.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=devis@oracolo.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain oracolo.com designates 209.85.215.42 as permitted sender) X-PHP-List-Original-Sender: devis@oracolo.com X-Host-Fingerprint: 209.85.215.42 mail-lpp01m010-f42.google.com Received: from [209.85.215.42] ([209.85.215.42:39160] helo=mail-lpp01m010-f42.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id DF/26-65129-F1CDBDE4 for ; Sun, 04 Dec 2011 15:46:25 -0500 Received: by lahc1 with SMTP id c1so263476lah.29 for ; Sun, 04 Dec 2011 12:46:20 -0800 (PST) Received: by 10.152.105.132 with SMTP id gm4mr4190053lab.39.1323031580300; Sun, 04 Dec 2011 12:46:20 -0800 (PST) MIME-Version: 1.0 Sender: devis@oracolo.com Received: by 10.152.43.70 with HTTP; Sun, 4 Dec 2011 12:45:39 -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 20:45:39 +0000 X-Google-Sender-Auth: FVIRzPUXm8H-qWYXUicxxg3bERc Message-ID: To: Tom Boutell Cc: PHP Internals Content-Type: multipart/alternative; boundary=f46d040715f55ed72404b34a4b73 Subject: Re: [PHP-DEV] Will apc.optimization ever be put back to APC? From: devis@lucato.it --f46d040715f55ed72404b34a4b73 Content-Type: text/plain; charset=UTF-8 Just an idea: it would interesting to have the optimisation running concurrently, to update the opcode cache with an optimised version, taking all the time it is needed for strong optimisations. If the optimisation is not ready for the first request it will be later when the optimisation is complete. The first hit would use the non optimised code, an optimiser would run to produce optimised opcode and eventually update APC cache. Starting with the second hit (or later if the optimisation takes time) the request would hit the faster cached opcode. Devis On 4 December 2011 19:55, Tom Boutell wrote: > 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > --f46d040715f55ed72404b34a4b73--