RE: [PHP-DEV] [PATCH] New, optimized is_numeric_string, and other number stuff
| From: | Andi Gutmans | Date: | Wed, 13 Dec 2006 07:12:17 +0000 |
| Subject: | RE: [PHP-DEV] [PATCH] New, optimized is_numeric_string, and other number stuff | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-26927@lists.php.net to get a copy of this message | ||
I briefly reviewed the patch and it looks interesting. Will take me a bit
longer though and I'd also like some others here to do so.
In any case, I think it's risky for PHP 5.2.1 and would prefer to defer it
to the next release even if I end up being in favor of including the patch.
It changes a lot of subtleties which can be dangerous in such a short time
frame.
Thanks for the patch. Will dig deeper now...
Andi
> -----Original Message-----
> From: Matt Wilmas [mailto:php_lists@realplain.com]
> Sent: Tuesday, December 12, 2006 6:58 AM
> To: internals@lists.php.net
> Subject: [PHP-DEV] [PATCH] New, optimized is_numeric_string,
> and other number stuff
>
> Hi all,
>
> I rewrote is_numeric_string/unicode to be faster and change a
> couple things.
> The changes being:
> 1) Previously, large numbers (very long or "1e500") that
> became INF were ignored (Bug #26349), which is not the
> behavior anywhere else.
> 2) Leading whitespace with hex numbers or ones that started
> with . (" .123") also caused them to be ignored.
> 3) Hex strings were limited to LONG_MAX, and in
> scripts/parser, ULONG_MAX.
> I added a zend_hex_strtod() function to handle numbers >
> LONG_MAX in both places. From the previous comments like
> "strtod() messes up hex numbers,"
> it seems there was desire to support them. :-)
> 4) Small change, but the string "0x" was considered
> non-numeric before, but a partial match of the 0 now
> (basically to get a more accurate error level/message with
> zend_parse_parameters(), for example).
>
> Now the performance... The errno stuff has been removed from
> is_numeric_* (and optimized in the parser) to save function
> calls with thread-safe libraries (are they used even when ZTS
> is disabled?). In my tests on Windows, I saw a 5-15%
> improvement with longs (less with more digits; on 64-bit
> systems, it could be slower at 12-15+ digits, but they're not
> common). (With HEAD, everything I checked was consistent,
> but in 5.2, a few random long tests were slower; must be some
> compiler weirdness? :-/) So not much difference there for
> these changes, BUT doubles are over *twice* as fast, and
> non-numeric string comparisons are up to nearly 3 times faster!
> (Slightly less % improvement in Unicode mode.) Yeah,
> non-numeric strings are detected very fast, which may be more
> significant since is_numeric_* is always used on them (from
> compare_function(), zendi_smart_strcmp(), etc.).
> Also, no number conversion is done if there's no
> corresponding pointer to fill -- much faster when code is
> "just checking."
>
> The larger inline function did increase the binary size by a
> few K... The
> patches:
>
> http://realplain.com/php/is_numeric.diff
> http://realplain.com/php/is_numeric_5_2.diff
>
> You can see that I changed MAX_LENGTH_OF_LONG to be accurate
> on 32-/64-bit, which my changes rely on. I also fixed a few
> places where memory calculations that use it could be too
> small, in theory.
>
> I wanted to get this in before Ilia's Thursday deadline (if
> it's still on :-)), in case it can be applied soon. Finally,
> don't know if you'd want to use it as is, but I've attached
> possible NEWS file updates about this stuff.
>
> Thoughts, questions? Thanks.
>
>
> Matt
>