Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:74408 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 80345 invoked from network); 21 May 2014 11:00:14 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 21 May 2014 11:00:14 -0000 Authentication-Results: pb1.pair.com smtp.mail=pierre.php@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=pierre.php@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.49 as permitted sender) X-PHP-List-Original-Sender: pierre.php@gmail.com X-Host-Fingerprint: 209.85.192.49 mail-qg0-f49.google.com Received: from [209.85.192.49] ([209.85.192.49:44947] helo=mail-qg0-f49.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id CE/D7-24198-D378C735 for ; Wed, 21 May 2014 07:00:13 -0400 Received: by mail-qg0-f49.google.com with SMTP id a108so2800092qge.8 for ; Wed, 21 May 2014 04:00:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=6pAZREqUM2SmfLS2JdwbjFCKn906eTWshEQ35dbsNGo=; b=A4+gXHGyoIe/ZDYjim3bl33GnaM628YbRHbOFnAL7Xw52ePZc6Gi1JDEPssDZ39Il1 icW45W5QT1sClwiYPgg0ssZili1G7xWQTYjScYnzkGmRnhQhI5zHgiGA2afE0LilzVkt BoEvFIPWvn53eUNyPMZmwloXYJ4NT1YDn59Eqx+IaU9PUEQD5OgfnQiDhpa0OL6umBFl 7mZAc1dyQF5ze8/k9fq2DZw/DawGCrywvIo5d4NiKUIEFujWNfFYiTVVuKRGsoA10FjS SdCcEXBE33N7W4Be7P+zQNpnaPVMk8jFJ7/rzLhaydkQeMzqJhHShdrZX/AItOUwIni7 Hs6g== MIME-Version: 1.0 X-Received: by 10.224.13.72 with SMTP id b8mr54042747qaa.4.1400670011157; Wed, 21 May 2014 04:00:11 -0700 (PDT) Received: by 10.140.47.231 with HTTP; Wed, 21 May 2014 04:00:11 -0700 (PDT) In-Reply-To: <79ebc4da038287be9faf56748d3ecdc4@mail.gmail.com> References: <537BC669.2030704@sugarcrm.com> <20140520230249.E326826082D@dd15934.kasserver.com> <266288285382887601@unknownmsgid> <79ebc4da038287be9faf56748d3ecdc4@mail.gmail.com> Date: Wed, 21 May 2014 13:00:11 +0200 Message-ID: To: Zeev Suraski Cc: Arvids Godjuks , Yasuo Ohgaki , "mails@thomasbley.de" , PHP internals Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] Re: 64bit and phpng, votes and plans From: pierre.php@gmail.com (Pierre Joye) On Wed, May 21, 2014 at 12:47 PM, Zeev Suraski wrote: > Last, there=E2=80=99s nothing slippery about *thinking about performance*= . We > should always think about performance with whatever we do. Much like > consistency or security, performance isn=E2=80=99t the one and only facto= r and > should be weighed against other factors, but it must be on the discussion > table on each and every thing we do. Also, performance is not at all > inherently contradictory to consistency, security or even code quality. > PHP 5.6 is almost twice as fast as PHP 5.0, and I=E2=80=99d argue the cod= ebase is > better and just as secure and consistent if not more. phpng is another > textbook example of how we (aka Dmitry, Xinchen and Nikita) managed to ge= t > 10-30% gains in real world performance without reducing the quality of th= e > code in any way, and arguably =E2=80=93 making it better. All this 100%+ > performance gains between 5.0 and phpng is tedious, extremely complex wor= k, > where individual changes rarely result in a boost of more than 3-5%. You > can imagine how much work it is to get to 100%+ improvements, and you > should therefore imagine why we don=E2=80=99t take lightly a change that = will undo > some of these gains unless we reach the conclusion they=E2=80=99re truly = justified, > as opposed to just being a matter of principle, or even being interesting > in rare uncommon cases. What you totally forget to mention: - we cannot refactor the core in a stable branch, not even using (much) better types remember? That's why you rejected and argued very hard against the 64bit RFC for 5.6, saying that it is all good for next (we can happily see the reasoning now...) - The next major version is a 2+ years effort. What does it mean? . open doors for deeper work and redesign than what we have done in the last decade . consistency and long due internals APIs and implementations cleanup is possible Now, one can still argue that it is still possible with phpng. But given the amount of changes brought by phpng, I have to say that the method used to implement it is by far not optimal. It not only causes a total freeze of any improvement (features or APIs) in the core until it reaches an alpha state, but it will also double the amount of work necessary to finalize it. A little cleanup of the core would have reduced the amount of work necessary to actually implement the ideas behind phpng, even more once you have seen that they are working well and are more than promising. This kind of things could have been avoided or done faster if Zend would have been more open about its current work. And one day, I will understand why NDAs and all this crap are necessary to work on php. Or maybe not. All in all it is bad for the php project (again, the project, not the results of what is being done), no matter the outcome of this patch. --=20 Pierre @pierrejoye | http://www.libgd.org