Re: zend_u_strtod() 400% speed up

Matt and Antony, I this we should go with Matt's patch, since we care only about ASCII characters in strings. -Andrei On Nov 13, 2006, at 4:46 AM, Matt Wilmas wrote:

Hi Antony, ----- Original Message ----- From: "Antony Dovgal" Sent: Friday, November 10, 2006

On 11/10/2006 02:14 PM, Matt Wilmas wrote:

Hi Antony, ----- Original Message ----- From: "Antony Dovgal" Sent: Friday, November 10, 2006

Hello all. I would like to propose a replacement for current zend_u_strtod()

implementation.

The patch: http://tony2001.phpclub.net/dev/tmp/u_strtod.diff According to my tests, new implementation is faster in about 40 (forty)

times.

The simple script below takes ~1 sec to run with the patch and ~40

seconds

without. Cool. :-) I'd just been thinking about zend_u_strtod() again -- if you

see

my thread asking Andrei about the Unicode characters allowed as

numbers...

I changed the function back in the summer to be about 8x faster by converting FROM Unicode and using the regular zend_strtod(), but it was

just

a quick hack, so maybe better that it wasn't applied! http://realplain.com/php/zend_u_strtod.diff

Hmm.. Actually, your version seems to be slightly faster (~15%) than mine and there are several advantages, like no formatter is required, avoiding parsing non-numeric strings and less TSRMLS_FETCH() calls, which leads to even better results on non-numeric strings. Also, it looks like a good idea to use zend_strtod() in both native and unicode modes.

Hmm, I don't understand how mine was faster if yours was 40x faster than the current version, as when I tested mine, it was only ~8x. :-/ Well anyway, as I mentioned in my first reply, I had another idea since I learned (from README.UNICODE and Andrei) that only ASCII digits are allowed in Unicode. I just put this together: http://realplain.com/php/zend_u_strtod.c I didn't test it (or even try to compile), but you get the idea -- "manually" copying the relevant Unicode chars to a char * (am I doing that right?). I've got the "char buf[64]" there, assuming it's more efficient than using emalloc() (?), when the number will fit. I didn't know what size to make it, just whatever catches the vast majority of cases... I'd really like to see a faster version implemented soon. :-) Matt