On Fri, 22 Oct 2004 13:49:53 -0700, Andi Gutmans <[EMAIL PROTECTED]> 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
