Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:65851 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 64220 invoked from network); 15 Feb 2013 01:59:29 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 Feb 2013 01:59:29 -0000 Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.193 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.193 smtp193.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.193] ([67.192.241.193:38781] helo=smtp193.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 29/50-62252-0869D115 for ; Thu, 14 Feb 2013 20:59:28 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp9.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 2E4813C0D7B; Thu, 14 Feb 2013 20:59:26 -0500 (EST) X-Virus-Scanned: OK Received: by smtp9.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id CF9743C0A52; Thu, 14 Feb 2013 20:59:25 -0500 (EST) Message-ID: <511D967D.6040604@sugarcrm.com> Date: Thu, 14 Feb 2013 17:59:25 -0800 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Terry Ellison CC: PHP internals References: <511BFC81.8020400@oracle.com> <7de2703f77537a47b457c4479a19ac3a@mail.gmail.com> <511D2BD6.2090903@sugarcrm.com> <511D93E3.3010707@ellisons.org.uk> In-Reply-To: <511D93E3.3010707@ellisons.org.uk> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Zend Optimizer+ Source Code now available From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > (A) The op-code optimization should be integrated into the core compiler > and enabled through a GC(compiler_option) to be available to *any* > opcode cache -- or to the application designer (by exposing these > options through an INI directive. Most optimizations would not give perceivable benefit unless the optimized code is run many times. So enabling it without opcode cache would not produce very big benefit. But yes, in theory these code parts can live separately and they don't actually need each other. > that support it). A Zend opcode cache belongs firmly in the Zend world > and shouldn't be a PHP extension. I must say I don't understand this conclusion. > I also note some interesting difference in approaches between O+ and > APC, say for example: > > 1) in the handling of the ZEND_INCLUDE_OR_EVAL instruction where APC > patches the op handler and O+ does peephole opcode examination. Both > these workarounds could be avoided by tidying up the scope of work in > the instruction code. Could you explain this a bit more? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227