Re: RESEND: NSMetadataItem performance issues
Re: RESEND: NSMetadataItem performance issues
- Subject: Re: RESEND: NSMetadataItem performance issues
- From: Vince DeMarco <email@hidden>
- Date: Wed, 3 Aug 2005 09:55:19 -0700
On Aug 2, 2005, at 5:05 PM, Hamish Allan wrote:
On 3 Aug 2005, at 00:46, Vince DeMarco wrote:
kMDItemPaths isn't cached its generated on the client as you need
it. So asking for kMDItemPath is going to be slow, only ask for
the Path of an item when you absolutely need it don't do it always.
Thanks for your reply. I was actually surprised at how fast it was
to obtain kMDItemPaths in general: the problem is that in certain
situations it's not just slow, but it takes 1 second for each
attribute to be fetched -- not just kMDItemPath but
kMDItemDisplayName, etc. It only appears to happen when
valueForAttribute: is called in the table redrawing code, i.e. at
the end of the run loop, which combined with the execution time of
almost exactly 1000ms made me think it might be a mutex issue? And
it mostly happens when lots of NSMetadataItems have previously been
fully instantiated describing the same results.
You get this quickly you need to do a bulk fetch using the Sortiing
attributes of MDQueryRef() and the two calls.
MD_EXPORT CFIndex MDQueryGetIndexOfResult(MDQueryRef query, const
void *result) MD_AVAIL;
and
MD_EXPORT const void *MDQueryGetResultAtIndex(MDQueryRef query,
CFIndex idx) MD_AVAIL;
Its not a mutex issue, each call to MDItemCopyAttribute() involves a
mach_message to the server, a context switch and a mach_message back
to you to return the result.
Vince
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden