Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69836
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain zend.com from 209.85.212.43 cause and error)
References: <CA+9eiLtNLdrP-b5YymTfnEpMVhUXDHhZ7u15mbjyNNv9Ev1ePQ@mail.gmail.com>
 <52686702.80107@oracle.com>
In-Reply-To: <52686702.80107@oracle.com>
MIME-Version: 1.0
thread-index: AQHbq93X02rcPT8yYLkPZ9piWVutRAIVpgXHmdklkQA=
Date: Thu, 24 Oct 2013 11:49:50 +0300
Message-ID: <6c41b1d2ddfa59832ec3422e14c12b10@mail.gmail.com>
To: Christopher Jones <christopher.jones@oracle.com>
Cc: PHP Internals <internals@lists.php.net>, Dmitry Stogov <dmitry@zend.com>
Content-Type: text/plain; charset=UTF-8
Subject: RE: [PHP-DEV] Improved performance of array_maerge() and func_get_args()
From: zeev@zend.com (Zeev Suraski)

> -----Original Message-----
> From: Christopher Jones [mailto:christopher.jones@oracle.com]
> Sent: Thursday, October 24, 2013 3:17 AM
> To: Dmitry Stogov; Julien Pauli; David Soria Parra; Stas Malyshev; PHP
> Internals
> Subject: Re: [PHP-DEV] Improved performance of array_maerge() and
> func_get_args()
>
>
>
> On 10/23/2013 05:36 AM, Dmitry Stogov wrote:
> > Hi,
> >
> > I'm proposing two simple patches that eliminate a lot of useless zval
> > copying.
> > For example they remove only about 800 calls to zend_hash_copy() (25%)
> > on each request to wordpress-3.6.0 home page and make it 2-4% faster.
> >
> > It's not a questions about master branch, but I think it is also safe
> > to commit them into PHP-5.4 and PHP-5.5.
> >
> > Any objections?
> >
> > https://gist.github.com/dstogov/7117623
> >
> > https://gist.github.com/dstogov/7117649
> >
> > Thanks. Dmitry.
> >
>
> I'd prefer PHP 5.4 was kept stable.
>
> Last time I suggested keeping PHP 5.4 stable [1], it wasn't, and the
> result was
> a performance regression [2].

I think the two are very different - this isn't some brand new complex
algorithm, but a very localized optimization that provides net gains in some
cases, with no real risk to other cases.

As far as I understand our release rules, as long as we break no APIs and no
ABIs - we can put it into presently shipping versions, as long as we're
confident it won't introduce regressions (which is true for any bugfix).

That said, I'm fine with us only putting it into 5.5 and not 5.4 to give
people a bit more motivation to upgrade;  It just doesn't make sense to sit
on it for a whole year, when the risk associated with it isn't that higher
than many other fixes we routinely introduce into bugfix releases all the
time...

Zeev