Re: NSMetadataItem performance issues
Re: NSMetadataItem performance issues
- Subject: Re: NSMetadataItem performance issues
- From: Hamish Allan <email@hidden>
- Date: Thu, 4 Aug 2005 19:42:05 +0100
On 4 Aug 2005, at 18:56, Vince DeMarco wrote:
Sorting is performed on the client not the server. So asking the
query to sort basically tells the server to send along all of the
sorting attributes no requests have to be made back to the server.
Ah; thank you. That explains the existence of
_NSMetadataQuerySortingPseudoItem!
What I'm doing at the moment is asking for the results unsorted, so
that each time I receive notification of new results I can add them
to my dictionary by just iterating over the most recent ones
(newResultCount - oldResultCount), which I presumably wouldn't be
able to do if I set sort descriptors. Is there any other way of
asking the server to send along all of a particular set of attributes
without them being sorting attributes?
The server is getting more and more overwhelmed and its taking
longer and longer.
Of course there are bugs in our code. But the Spotlight menu is
doing what i'm suggesting here and i don't have this particular
performance problem (I do have others though, which i am working on
fixing right now)
I'm sorry, I'm not trying to give you a hard time, just trying to get
to the root of the problem. I still don't see how it can be as
straightforward as the server being overwhelmed, because surely I
would be seeing attribute fetch times of between, say 10ms and 990ms,
which I'm not.
If you're interested, you should be able to reproduce the problem
using the XCode project at http://igor.gold.ac.uk/~map01ra/
SpotTest.zip. Try a query with a few thousand results several times,
watch the log, and see the dichotomy between the fast and the slow
lookup times.
Thanks again,
Hamish
_______________________________________________
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