Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89796
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.44 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <56695EFB.2090709@lsces.co.uk>
References: <56662437.5040508@lsces.co.uk>
	<ED195E5D-1F00-401B-86EA-2B8C81592A79@lerdorf.com>
	<27359E8F-2C04-416B-861D-C2C4C85E4C77@lerdorf.com>
	<5666CDDD.6030209@lsces.co.uk>
	<5667A477.1060308@gmail.com>
	<566855AC.30808@gmail.com>
	<56687ACA.5090309@lsces.co.uk>
	<CALrkBjYqNkCVWmLREfE9aNM=dpMH_+F4SST60QF3bKREpqui8A@mail.gmail.com>
	<56695BCA.9090305@telia.com>
	<56695EFB.2090709@lsces.co.uk>
Date: Thu, 10 Dec 2015 09:08:24 -0800
Message-ID: <CAFWS2+EBu23khp8f9L1_sOLc7aGMgsxGndap-u30d3DBjuOhPg@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11411d2a2edfd105268e4118
Subject: Re: [PHP-DEV] Practical comparisons on PHP7
From: ronabop@gmail.com (Ronald Chmara)

--001a11411d2a2edfd105268e4118
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Dec 10, 2015 at 3:16 AM, Lester Caine <lester@lsces.co.uk> wrote:

> On 10/12/15 11:02, Bj=C3=B6rn Larsson wrote:
> > Just noticed that Smarty team is working on a 3.1.28 relase that plans
> > to be PHP 7 compliant, see: https://github.com/smarty-php/smarty
> The version I'm running is not giving any errors, similarly ADOdb. Both
> were brought up to be clean on PHP5.4 and that seems to be the case with
> most BC problems. BUT should either of these packages need any 'major
> upgrade' to take advantage of a faster PHP7?


Few software stacks should need any major changes to use PHP7.

They are e_strict compliant
> and well structured so why would they not perform twice as fast on PHP7?


If a portion of a stack is poorly architected, poorly written, or poorly
implemented, the gains in moving to PHP 7 may be negligible.

PHP7 does not double the speed of accessing or updating databases, so if a
page is bogged down by an large amount of DB queries, PHP7 will not fix
that.

PHP7 does not double the speed of filesystem reads and file writes, so if a
page has significant amounts of local filesystem access (say, using
class/file auto-loaders, or messes around with a whole bunch of template
files, data files, whatever) PHP7 will not fix that.

PHP7 does not double the speed of network interactions, so if a page has
significant amounts of network access (say, pulling data from other URL's,
) PHP7 will not fix that.

PHP7 does not double the execution speeds of non PHP library calls, so for
example, (in addition to db access libraries) image manipulation libraries,
PDF builders, (etc.) will not see increased execution speeds, as they are
outside of PHP7.

...Those are just some of the low hanging fruit I've run into professionaly
that have showed big gains in addressing.

There are lots of possible reasons why PHP7 will show dramatic improvements
for some, and little improvement for others. The "PHP7 may double speeds"
holds true for certain kinds of PHP code, and usage, but if a page is
currently bogged down with crap code, or external calls to things outside
of PHP, the overall gains in changing to PHP7 may not be dramatic.

-Ronabop

--001a11411d2a2edfd105268e4118--