Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:43415
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain realplain.com from 209.151.69.1 cause and error)
Message-ID: <62A879A44B7A45AAB19266AB34ECDFA6@pc1>
To: <internals@lists.php.net>,
	"Dmitry Stogov" <dmitry@zend.com>
Cc: "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>
Date: Thu, 19 Mar 2009 10:32:33 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=response
Content-Transfer-Encoding: 7bit
Subject: Re: [PATCH] Bug #45877: LONG_MAX/MIN array key as string/int
From: php_lists@realplain.com ("Matt Wilmas")

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