Thread-topic: Binary property list efficiency issue
User-agent: Microsoft-Entourage/11.2.1.051004
On Fri, 20 Jan 2006 02:16:39 -0500, Laurence Harris <email@hidden>
wrote:
> On 1/19/06 8:41 PM, John Stiles didst favor us with:
>
>> Have you Sharked it? Even if it's all inside Apple code, their
>> function names are usually descriptive enough that you can get a
>> picture of what's going on behind the scenes.
>
> Well, we've Sharked it now. Shark shows that 44%+ of the time is
> spent __plistUniquingEqual(), followed distantly with 12% in
> __CFNumberGetValue(). Looking at the CF source, it looks like most of
> the time involved here is spent in the inline CFTypeID comparison,
> since CFEqual() is far, far behind anything of time significance in
> the trace. CFNumberGetType() came in an even further third, with some
> 9% of the total time. Shark also reveals that __plistUniquingEqual()
> is poorly optimized (not inlined and often returns early). All of this takes
> place inside CFSet. In the worst-case scenario, uniquing should be turned
> off completely. Even without it, the binary plist is going to be smaller
> than XML.
>
> 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.
_______________________________________________
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
