Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:10520
Return-Path: <hartmut@php.net>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 7404 invoked by uid 1010); 16 Jun 2004 13:45:12 -0000
Delivered-To: ezmlm-scan-internals@lists.php.net
Delivered-To: ezmlm-internals@lists.php.net
Received: (qmail 7283 invoked from network); 16 Jun 2004 13:45:10 -0000
Received: from unknown (HELO mailgate.mysql.com) (213.136.52.47)
  by pb1.pair.com with SMTP; 16 Jun 2004 13:45:10 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mailgate.mysql.com (8.12.10/8.12.10) with ESMTP id i5GDj8Ho016470;
	Wed, 16 Jun 2004 15:45:08 +0200
Received: from mail.mysql.com ([10.222.1.99])
 by localhost (mailgate.mysql.com [10.222.1.98]) (amavisd-new, port 10026)
 with LMTP id 08769-06; Wed, 16 Jun 2004 15:45:08 +0200 (CEST)
Received: from php.net (mailsend.mysql.com [10.100.1.123])
	(authenticated bits=0)
	by mail.mysql.com (8.12.10/8.12.10) with ESMTP id i5GDiwQ6022012;
	Wed, 16 Jun 2004 15:45:00 +0200
Message-ID: <40D04E45.6080407@php.net>
Date: Wed, 16 Jun 2004 15:42:29 +0200
Reply-To: hartmut@php-groupies.de
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en, de
MIME-Version: 1.0
To: Alexander Valyalkin <valyala@tut.by>
CC: internals@lists.php.net
References: <opr9my6xi2t8r34v@valyala> <1087335679.40cf6cff249fc@hristov.com> <opr9og1buht8r34v@valyala>
In-Reply-To: <opr9og1buht8r34v@valyala>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at mailgate.mysql.com
Subject: Re: [PHP-DEV] strspn() & strcspn() speed improvements
From: hartmut@php.net (Hartmut Holzgraefe)

Alexander Valyalkin wrote:
> On Wed, 16 Jun 2004 00:41:19 +0300, Andrey Hristov <php@hristov.com> wrote:
> 
>>   Privet Alex,
>> is it possible to show some results from benchmarking?
 >
> Just compile my standalone test & view results :)

As noted before: standalone benchmarks can only tell you whether ot not
it is worth the effort to implement a change within PHP *and benchmark
it as a whole*.  Some changes may not show a difference as the code
is not on a critical path, some may only improve performance on certain
platforms while hitting it on others, sometimes even in very unexpected
circumstances. (i could continue almost forever ...)

Besides that the good old rules of engineering applies:

  "If it ain't broken -> don't fix it"

and

  "Never change a running system!"

I'm sure there are lots of places within PHP that deserve code reviews
and performance improvements, but especially now, in a feature freeze,
it is important to act in accordance to the rules above. Any changes in
code come with the risk of introducing new errors. Especially those
that seem "simple" bear this risk. To keep this risk as low as possible
only bug fixes are allowed in a feature freeze. A "lack of performance"
is in this case only considered a bug if it *substantialy* hurts
performance.

PHP has become a very complex piece of software. Its developement
process has also become very complex. Do you really think you can
just jump in out of nowhere, throw patches at us, telling us that we
are all too stupid to write efficient code and still be taken serious
as the great savior?


-- 
Hartmut Holzgraefe  <hartmut@php.net>