Re: [PATCH] Bug #45877: LONG_MAX/MIN array key as string/int

From: Date: Thu, 19 Mar 2009 15:32:33 +0000
Subject: Re: [PATCH] Bug #45877: LONG_MAX/MIN array key as string/int
References: 1 2 3 4 5 6  Groups: php.internals 
Request: Send a blank email to internals+get-43415@lists.php.net to get a copy of this message
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

« previous php.internals (#43415) next »