Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74407
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain zend.com from 209.85.220.174 cause and error)
References: <CAEZPtU4mrOiBzbqZdvxbgxseGo3ZzwgiinkqsgLQEZebrAke6w@mail.gmail.com>
 <CA+9eiLsMtcYVSvzHW_oc1dXNrDBH8RQ-cb1MgKB5ef2i2mQX7g@mail.gmail.com>
 <CAEZPtU7Tacn2GS0REbikcn8XKQr04vve=LsGQJZrkUh2oHZsuA@mail.gmail.com>
 <CA+9eiLu8tgsitvZ0DUCqE8ahQPwE9rDhL9JVzQ5P6meVut4H_w@mail.gmail.com>
 <CAL0xaBHtsKZr=9V7GLg=K=EjMzObnxUoxjNCd_am7nqFZR1vqA@mail.gmail.com>
 <CAGa2bXZUCtswupfixjpu7=BG0_dajApxmF8vEWUdZs9mtPnn_w@mail.gmail.com>
 <CAF+90c85gpvXheKuLtPYs0TN7E=ynb9ALqMuckT60zVWXYZoGg@mail.gmail.com>
 <CAGa2bXZFiJCasezvuuBc+K67j4W5dCgMVartEUqZrZp+z0JrBA@mail.gmail.com>
 <CAGa2bXbb6YjTXrL61C0cshXEBBbzYg8HQb7MocJ0GsmAy9sz9w@mail.gmail.com>
 <537BC669.2030704@sugarcrm.com> <CAGa2bXa1L4-ok-i8k3W-7zbpea-AU0fYJq0bY32fqEbh4DMFVA@mail.gmail.com>
 <20140520230249.E326826082D@dd15934.kasserver.com> <CAGa2bXYFUqRskjBL5ZwNQ_TfPJ9tO0Gqg=cn7Ws-j+qF3UCSTQ@mail.gmail.com>
 <266288285382887601@unknownmsgid> <CAEZPtU7RtqL9j_bmd64B1QJLKc3uwrLpyqq3kM9Q4q47TSSZgQ@mail.gmail.com>
 <CAL0xaBHBiaXB0x+qKX=oq3RX9cRB2FPk+8mGYP7gzV9+FOcYNw@ma il.gmail.com>
In-Reply-To: <CAL0xaBHBiaXB0x+qKX=oq3RX9cRB2FPk+8mGYP7gzV9+FOcYNw@mail.gmail.com>
MIME-Version: 1.0
Thread-Index: AQJ04zgkRUVwbv11086EJrGQvaMdywEXaCCxAkfJhOgB78F+TQD7FCATAWjtWj0CrBl6OQItFbALAcjFut8BoPligAGvSEl7AoAoxRcBQCyDwQIkjvvEAroPpTECYmtSw5kaqctg
Date: Wed, 21 May 2014 13:47:00 +0300
Message-ID: <79ebc4da038287be9faf56748d3ecdc4@mail.gmail.com>
To: Arvids Godjuks <arvids.godjuks@gmail.com>
Cc: Yasuo Ohgaki <yohgaki@ohgaki.net>, mails@thomasbley.de, internals@lists.php.net
Content-Type: multipart/alternative; boundary=047d7b67778666369c04f9e6b7fb
Subject: RE: [PHP-DEV] Re: 64bit and phpng, votes and plans
From: zeev@zend.com (Zeev Suraski)

--047d7b67778666369c04f9e6b7fb
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Performance always had and will have the flipside - you either make an
extremely fast, but somewhat messy code, or you sacrifise some performance
and make a better code.

same goes for consistensy - you have to sacrifise some performance for it.
The hard thing always is to balance it all. No mere 2%-5% performance
increase or decrease will affect a poorly written system - it will probably
get a tripple number performance improvement if just redisigned and rebuilt=
.



I think we=E2=80=99ve spent enough on this topic, and I don=E2=80=99t us wa=
nt to get
carried into it yet again.  Consistency is not an ultimate goal that gives
us a carte blanche to do whatever changes necessary regardless of the
cost.  It=E2=80=99s one factor out of several.  Its weight depends on **wha=
t** kind
of consistency we=E2=80=99re talking about, and whether it makes sense for =
the
majority of our userbase.



Performance isn=E2=80=99t an ultimate goal either.  I am absolutely *not* t=
hinking
about performance alone, nor do all of the core devs that opposed many of
the =E2=80=98consistency changes=E2=80=99 that were proposed.  If we did we=
=E2=80=99d oppose any
and all elements of the patch, which isn=E2=80=99t the case.  But performan=
ce is
another extremely important factor, which is why we weighed the benefit
versus cost of each part of the change and framed our opinions about it.
Nikita came up with a sensible compromise =E2=80=93 which was the goal all =
along -
and it gained consensus very quickly.



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 factor =
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 codeb=
ase 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 get
10-30% gains in real world performance without reducing the quality of the
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 work,
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 wi=
ll undo
some of these gains unless we reach the conclusion they=E2=80=99re truly ju=
stified,
as opposed to just being a matter of principle, or even being interesting
in rare uncommon cases.



Zeev

--047d7b67778666369c04f9e6b7fb--