Re: [PATCH] Bug #45877: LONG_MAX/MIN array key as string/int
| From: | Matt Wilmas | 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:I know. :-)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.
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...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.
Thanks. Dmitry.Again, sorry I was about 20 minutes late with this! :-( - Matt