Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:84009 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 77736 invoked from network); 27 Feb 2015 15:09:48 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 27 Feb 2015 15:09:48 -0000 Authentication-Results: pb1.pair.com header.from=bobwei9@hotmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=bobwei9@hotmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.116.45 as permitted sender) X-PHP-List-Original-Sender: bobwei9@hotmail.com X-Host-Fingerprint: 65.55.116.45 blu004-omc1s34.hotmail.com Received: from [65.55.116.45] ([65.55.116.45:63770] helo=BLU004-OMC1S34.hotmail.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id A1/53-32582-9B880F45 for ; Fri, 27 Feb 2015 10:09:45 -0500 Received: from BLU437-SMTP88 ([65.55.116.7]) by BLU004-OMC1S34.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Fri, 27 Feb 2015 07:08:34 -0800 X-TMN: [4/r+v2kOG/OsHK0Nt8FROnjKE2poWjqx] X-Originating-Email: [bobwei9@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="Apple-Mail=_420B37C1-A51E-471F-9DB9-0971056D60AB" MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) In-Reply-To: Date: Fri, 27 Feb 2015 16:08:29 +0100 CC: PHP Internals , Dmitry Stogov References: To: Xinchen Hui X-Mailer: Apple Mail (2.2070.6) X-OriginalArrivalTime: 27 Feb 2015 15:08:32.0588 (UTC) FILETIME=[404E10C0:01D0529F] Subject: Re: About optimization for compiler From: bobwei9@hotmail.com (Bob Weinand) --Apple-Mail=_420B37C1-A51E-471F-9DB9-0971056D60AB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" > Am 27.02.2015 um 07:53 schrieb Xinchen Hui : >=20 > Hey: >=20 > On Fri, Feb 27, 2015 at 2:22 PM, Xinchen Hui > wrote: >> Hey Internals: >>=20 >> I was looking Bob's switch optimization.. > And, I am not against this switch optimization.. >=20 > I referring it to show where is my concerns came from >=20 > thanks >>=20 >> then I start to worry about where is the place optimization = should goes.. >>=20 >> in generally, PHP is a interpreted language. IMO, it should >> compiler the PHP codes to opcode without any optimization(of course, >> we did some, but they won't change a lots of opcodes which should be >> generated).. >>=20 >> and, since 5.5, we already have opcache bundled in.. >>=20 >> thus, I am proposing a principle, that is: >>=20 >> in the future, we only do optimization in opcache side, and keep >> Zend Compiler without any optimization... considering Zend Compiler = do >> things in -O0. >>=20 >> since, optimization always are dangerous.. if we only do them in >> opcache, user can still run them codes with disable opcache, or at >> least disable some optimization level which cause that.. >>=20 >> what do you think? >>=20 >> thanks >>=20 >> -- >> Xinchen Hui >> @Laruence >> http://www.laruence.com/ >=20 >=20 >=20 > --=20 > Xinchen Hui > @Laruence > http://www.laruence.com/ Hmm. I'm not sure, but do we really want to have the optimizations = depending on opcache? I'd rather shift to slowly adding the optimizations into Zend/, in = separate compiler steps you can (like in opcache too) enable and = disable. It's actually a bit weird to have to include opcache just for its = optimizations. Opcache should do what its name says: the sole task of = caching the op_arrays. We need to change an extension for nearly every little change in Zend/. = That shouldn't be the case either. But just to say, it's not only a minor optimization, in a real world = stateful parser it makes a difference of a few percent. And also, this optimization only adds a ZEND_SWITCH opcode, nothing = more. (except in case we can determine at compile-time where the switch = land, then it will be optimized out to a simple JMP) Bob= --Apple-Mail=_420B37C1-A51E-471F-9DB9-0971056D60AB--