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

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