Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70493
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <759ccd0f06663defc84ffee473b51210@mail.gmail.com>
References: <CA+9eiLuSBF9NVqnGV8Oe1Dn-tBQ_86h2PGsFuJhr0_Wv9jYoZg@mail.gmail.com>
	<op.wx532ugqidpuyk@damnation.nl.lo.geleia.net>
	<CA+9eiLtpKjJtF9K7xBnftmzjEd92C6rLu-k+0RW1wfc60_oLtg@mail.gmail.com>
	<op.wx6g9ftzidpuyk@damnation.nl.lo.geleia.net>
	<CABBJUpdvzkO-p6mKtGnrrxdAvXgRp8GHzEGazjibCSicOgS9Eg@mail.gmail.com>
	<529D1197.5000305@nebm.ist.utl.pt>
	<8BCA5A38-788B-4E6A-A6AC-1A8DCBA3D8D9@zend.com>
	<CADNQb0XtN2zeLEb-bGm5L6rfH+7KomOVgmqaxwp4fQcceOMcgQ@mail.gmail.com>
	<759ccd0f06663defc84ffee473b51210@mail.gmail.com>
Date: Tue, 3 Dec 2013 08:18:45 -0800
Message-ID: <CADNQb0WRs_rTJ2VhxD1kd1GkNH9mjYf87j2-1Em6h-69W2trkg@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: Andi Gutmans <andi@zend.com>, Gustavo Lopes <glopes@nebm.ist.utl.pt>, Laruence <laruence@php.net>, 
	Dmitry Stogov <dmitry@zend.com>, PHP Internals <internals@lists.php.net>, Gadi Goldbarg <gadi@zend.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] strtr() performance degradation
From: hannes.magnusson@gmail.com (Hannes Magnusson)

On Tue, Dec 3, 2013 at 12:29 AM, Zeev Suraski <zeev@zend.com> wrote:
>> -----Original Message-----
>> From: Hannes Magnusson [mailto:hannes.magnusson@gmail.com]
>> Sent: Tuesday, December 03, 2013 9:34 AM
>> To: Andi Gutmans
>> Cc: Gustavo Lopes; Laruence; Dmitry Stogov; PHP Internals; Zeev Suraski;
>> Gadi Goldbarg
>> Subject: Re: [PHP-DEV] strtr() performance degradation
>>
>> On Mon, Dec 2, 2013 at 10:54 PM, Andi Gutmans <andi@zend.com> wrote:
>> >
>> > On Dec 2, 2013, at 3:02 PM, Gustavo Lopes <glopes@nebm.ist.utl.pt>
>> wrote:
>> >>> =E2=89=88
>> >>
>> >> The progress consists of writing of scripts to test the point where t=
o
>> >> switch
>> algorithms and trying some improvements on the old one without as
>> expensive preprocessing steps.
>> >>
>> >> Now, this was in the summer... I'll have some time in the holidays to
>> >> pick
>> up this and some other PHP-related backlog; that said, if there's some
>> impatience (which would be perfectly understandable...), I wouldn't mind
>> if
>> someone reverted to the previous state in the meantime.
>> >
>> > Sounds like this may take some time to figure out. So if there is
>> > absolutely
>> no difference in semantics between the two I would suggest we revert unt=
il
>> you are able to dig into this.
>> >
>>
>>
>> This change was included in 5.4.12 and 5.4.22 has been released.
>> Now you want to revert and maybe release 5.4.23 and then apply again in
>> 5.4.24?
>>
>> That doesn't seem worth it. What done is done. Had it been reverted righ=
t
>> away then it would have make sense, but not 10 releases later?
>
> Hannes,
>
> To put things in perspective, the work that goes into improving PHP's
> performance by 10% is measured in months, sometimes more (from inception =
to
> production).  Here, we have a patch that slowed real world apps (not
> synthetic benchmarks) by over 10%, and despite the fact it was reported 6
> months ago, we've done absolutely nothing about it.  If anything in that
> story doesn't make sense, that would be it.


Agreed. The release manager messed up. He should have been paying
attention and never shipped the release.

And oddly enough, the 5.5.0 release (released just couple of weeks
after the initial mail in this thread) also included this wrong-fix
without anyone caring.

And to this date, I am unable to find a bug report complaining about a slow=
down.



> As to when we reintroduce it - I think it's absolutely fine that we don't
> reintroduce it in the 5.4.x series, or even the 5.5.x series, but slate i=
t
> to 5.6.0 - and that too only if it's fully-baked by the time 5.6.0 is rea=
dy.


I think optimizations of this kind shouldn't be committed into bugfix
releases anyway.
We are rolling out bugfix releases these days like we are trying to
catch up with browser versions, and minor releases so frequently that
kids use to to learn how to count.
Optimizations should be considered a major feature and only added to
.0 releases so this doesn't happen.


> We've all experienced first-hand what a complete rewrite of a very popula=
r
> piece of code can do, and the fact that compatibility can be broken not j=
ust
> by changing behavior, but also by radically changing the algorithm in a w=
ay
> that produces very negative performance side effects.  Performance should=
 be
> one of the measures by which we weigh compatibility - a major regression =
in
> performance shouldn't be acceptable any more than a major regression in
> functionality.

Completely agree, further strengthening my argument that bugfix
releases should be left out of this.


>
> We should revert this patch ASAP;  It's unfortunate we haven't done it ba=
ck
> when it was found but better late than never.

I don't know... Noone cared when it was released, noone has reported a
ticket, can't we leave stable branches stable and fix this in the
upcoming minor release?

-Hannes