Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:43425
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.163 as permitted sender)
Message-ID: <49C39218.6000209@zend.com>
Date: Fri, 20 Mar 2009 15:54:48 +0300
User-Agent: Thunderbird 2.0.0.19 (X11/20090105)
MIME-Version: 1.0
To: Matt Wilmas <php_lists@realplain.com>
CC: internals@lists.php.net, Lukas Kahwe Smith <mls@pooteeweet.org>, 
 =?ISO-8859-1?Q?Johannes_Schl=FCter?= <johannes@php.net>
References: <1113CE12226949C2939A31971420991F@pc1> <49C0A7C7.8000804@zend.com> <12E613FAA1C9422B948F00B61AD32366@pc1> <49C134E5.7020706@zend.com> <570D833B543A4EB599F982488CDC41E4@pc1> <49C1E2ED.8080907@zend.com> <62A879A44B7A45AAB19266AB34ECDFA6@pc1>
In-Reply-To: <62A879A44B7A45AAB19266AB34ECDFA6@pc1>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PATCH] Bug #45877: LONG_MAX/MIN array key as string/int
From: dmitry@zend.com (Dmitry Stogov)

Hi Matt,

I ran you version but it looked little bit slower (I checked it with 
callgrind). So I kept the current CVS version. Anyway, it is not a big 
problem to change it after RC.

Thanks. Dmitry.

Matt Wilmas wrote:
> Hi Dmitry,
> 
> ----- Original Message -----
> From: "Dmitry Stogov"
> Sent: Thursday, March 19, 2009
> 
>> Hi Matt,
>>
>> Matt Wilmas wrote:
>>> Hi again Dmitry,
>>>
>>> Just wanted to say that I think I can make your code a bit smaller 
>>> after looking at it closer.
>>
>> It would be great, but keep in mind that performance is more important.
> 
> I know. :-)
> 
>>>  Don't quite have enough time to modify and verify it now, but I'll 
>>> be back later (around the usual time) to let you know either way. :-)
>>
>> I'm waiting for your changes.
> 
> No patch, but here's the straight code: 
> http://realplain.com/php/handle_numeric.txt
> 
> With your benchmark script, if I changed one of the keys, it would 
> sometimes radically affect the time of another key value, hmm.  But in 
> my own tests, this was always faster.  Some notes:
> 
> I've never understood why the terminating null check is there...  I 
> don't see why it would be missing if there aren't other problems in 
> code.  A place for UNEXPECTED()?
> 
> I removed the special handling of "0" and it's faster.
> 
> (Oh no, I see you just commited your code right now, LOL.  Sorry I 
> didn't send this sooner. :-/)
> 
> For the leading 0 check, I changed it back to "length > 2" again instead 
> of the "end - tmp != 1" calculation.
> 
> I used ++tmp instead of 2 *tmp++ because I assume having the increment 
> in just one place creates less instructions. ;-)  (For size, not speed.)
> 
> Finally, in the Unicode version (copied, untested), I'm using the 0x 
> values that were there originally instead of '0' char values...
> 
>> Thanks. Dmitry.
> 
> Again, sorry I was about 20 minutes late with this! :-(
> 
> - Matt