Re: Re: PHP 5.1 roadmap
| From: | Wez Furlong | Date: | Fri, 22 Oct 2004 23:41:47 +0000 |
| Subject: | Re: Re: PHP 5.1 roadmap | ||
| References: | 1 2 3 4 5 6 7 8 9 10 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-13481@lists.php.net to get a copy of this message | ||
On Fri, 22 Oct 2004 13:49:53 -0700, Andi Gutmans <andi@zend.com> wrote:
> At 10:13 AM 10/22/2004 +0100, Wez Furlong wrote:
> >I'd like to get LFS support into 5.1; it kinda needs int64 support. I
> >would be happy with a ZVAL_INT64() macro that assigns an int64 type to
> >a zval; for now it would represent the value as a long if it is <
> >LONG_MAX, but as a string otherwise. This would solve the problem of
> >returning a meaningful value to the script. We could also add an "L"
> >placeholder to zend_parse_parameters() that would handle the reverse
> >of this. I know this isn't a brilliant solution, but it is equivalent
> >to what other int64 extensions are doing, and it would be good to have
> >this centralized.
>
> Yeah that sounds like something which might work or use a float?
I'm not sure if float will be precise enough :-/
> I saw someone mentioned the performance of serialization.
That was me.
> Maybe we should have a competition similar to the longlong2str that MySQL
> had a few years ago :)
> Who writes the fastest and best written serialization/unserialization
> routines for zval's.
The specific case I had was serializing an array containing a whole
bunch of arrays representing the data from tables in a database. I
don't recall how many rows there were, but the serialized data was
around 5 MB. This was on windows, and feels like realloc doing
over-time, so a fix could be something as simple as tweaking the
smart_str chunking code; start with a fair initial size and perhaps
having it double the size on each realloc.
Of course, a competition for the fastest serializer would be nice too :)
--Wez.