Unfortunately, the table is not KVO-compliant so I cannot use NSSortDescriptor. And I need to pass the primary and secondary sort fields at runtime, so I cannot use sortUsingSelector since it takes no parameters.

NSSortDescriptor requires an object be *KVC* compliant. It does not use KVO. Since KVC does a pretty good job of inferring keys from method names, typically one has to actually put some effort into breaking KVC compliance.

Now, NSSortDescriptor does cache some of the results from KVC, so I suppose if you're doing something pretty whacky like having fake keys that return the result of a computation every time (like "random" or a series) you might not get the results you expect. Of course, trying to sort on such a key is probably semantically meaningless, so I hereby assert NSSortDescriptor's behavior is still correct ;)

I am using sortArrayUsingFunction: context: to sort a fairly large table (100k recs). Judging from the readout of comparisons being made the sort appears to be about 80% done when everything comes to a halt. No message, no nothing. It just stops.

Run it in gdb, then hit control-C. What does it look like in top ? Is your heap huge ? Is the machine thrashing (swapping to disk) ?

Also, if it's a stray pointer problem, you could try guard malloc (man libgmalloc)

I'd really appreciate suggestions on how to 1) get through this file using the function I set up and 2) ideas on alternative approaches that will be able to handle much larger files for the future.

Sorting much larger files will require some effort on your part.

First, you'll want to tune your current performance. Creating temporary objects during the comparison function is bad. If you absolutely have to, make sure you use -alloc/init and explicitly -release and avoid autorelease objects and objects from convenience constructors. -autorelease just won't fly in a comparison method for a 100,000 objects. This may mean your accessor methods need to be changed so they don't impair the comparison method.

You definitely don't want to work with all the data at once. You want to stream through it in a nice batch size, which is large, but nothing that will put memory pressure on the overall system. Depending on your system and deployment target that could 10MB or 100MB. Typically there are diminishing returns as the batch size grows, so some empirically testing (binary search style) should quickly give you an idea.

One nice thing about sorting, is that this is easy to do: merge sort. You can break up the problem as much as you want, and use any handy sort function, and then merge the pieces together.

Algorithms for merging are readily available on the net. Ask google. It's about 1 page of code to use qsort_r() and a hand written merge function.

Merge sort is trivially parallelizable with NSOperationQueue, so you can speed things up more when you're ready to tackle that. It's 1 page of code to allocate, build dependencies, and run a fully concurrent merge sort this way.
--

-Ben
_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Reply via email to