On 1/20/06 3:12 AM, Matt Gough didst favor us with:
>
> On 20 Jan 2006, at 07:16, Laurence Harris wrote:
>
>> Here are some times I got in testing. Property list has a small
>> header which
>> is the same size for every list and a main array. All times are the
>> time
>> spent in CFPropertyListWriteToStream:
>>
>> 1,538 items:
>> binary 1.65
>> XML 0.317
>>
>> 8,365 items:
>> binary 63.58
>> XML 0.933
>>
>> 31,041 items:
>> binary 1499.033 secs
>> XML 3.583 secs
>>
>> The XML times go up linearly. The binary times appear to be going up
>> exponentially. This makes the binary format completely unusable for
>> large
>> lists with its current implementation. I can't ask users to wait 25
>> minutes
>> while I save a file.
>
> Larry,
>
> This reminds me of a similar situation with Cocoa Archiving. I think
> the Binary version is trying to only add each 'duplicated' value for
> everything only once and then just inserting a reference to the
> original each time a duplicate is encountered. The plain version is
> obviously not allowed to do this. Hence as the list gets bigger, the
> time to compare each item against all the others grows exponentially.
I believe this is what's happening. Seems like CFSet should use a more
efficient mechanism for handling this, though.
> If you want to save space, I would suggest creating a text property
> list into memory and then using zlib to compress that down. I suspect
> that will be a lot quicker, if not maybe so small overall.
Hmm. Interesting. Plenty to think about here. Thanks to everyone for the
thoughts.
Larry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden
This email sent to email@hidden
