RE: [PHP-DEV] strtr() performance degradation

> -----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: > >>> ≈ > >> > >> The progress consists of writing of scripts to test the point where to > >> 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 until > 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 right > 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. 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 it to 5.6.0 - and that too only if it's fully-baked by the time 5.6.0 is ready.. We've all experienced first-hand what a complete rewrite of a very popular piece of code can do, and the fact that compatibility can be broken not just by changing behavior, but also by radically changing the algorithm in a way 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. We should revert this patch ASAP; It's unfortunate we haven't done it back when it was found but better late than never. Zeev