Re: sort descriptor optimization
Re: sort descriptor optimization
- Subject: Re: sort descriptor optimization
- From: Matt Neuburg <email@hidden>
- Date: Tue, 04 Jul 2006 16:44:44 -0700
- Thread-topic: sort descriptor optimization
On or about 7/4/06 3:43 PM, thus spake "Adam R. Maxwell" <email@hidden>:
>> But you're doing this in such an odd way. Why are you subclassing
>> NSSortDescriptor at all? NSSortDescriptor itself tells you how it
>> wants you
>> to deal with this sort of situation; as it stands, it can be
>> initialized
>> with a comparison method selector. So, for example, if your
>> comparands are
>> NSStrings, you could implement a special comparator (via a category on
>> NSString) and use it in your NSSortDescriptor. Do you see the same
>> sort of
>> slowdown using that architecture?
>
> We considered that. However, our users want nil values and empty
> strings to sort last in an a-z ordered list, instead of first, for
> all objects. Implementing this in NSSortDescriptor was also less
> code, and doesn't require adding a special category on every object
> that we sort.
I don't see that. You could make this a category on NSObject and put your
"less code" into one method that would probably look very much like the
method you're using now.
>> As for some of your comparands being nil values, the obvious
>> suggestion is,
>> Don't Do That. m.
>
> Thanks, but that is not an option. We need valueForKey: to return
> nil when there is no value for that key.
You can say you don't feel like doing it, but to say it's not an option is a
bit strong, since this is exactly the sort of thing NSNull is for - an
object that functions as a marker for nil-ness. For example, in talking to a
MySQL database I have wanted to distinguish between a result that is an
empty string and a lack of result - and the difference between @"" and
[NSNull null] has solved the problem perfectly.
I'm just suggesting that once you've got nothing but objects, they can
compare themselves to one another and be displayed through the interface in
any manner you desire. And then you'd be doing things in the way that an
NSSortDescriptor expects, according to the docs. I don't know that this
would be faster, but at least you wouldn't be doing something unusual and
then complaining that it doesn't work.
Still another possibility, of course, might be not to use an
NSSortDescriptor at all. For example, if your container is an array, there's
NSArray's sortedArrayUsingFunction. That could be way faster, because the
overhead of method calls goes away. I've got quite a lot of code that works
that way, left over from the dark days before we had NSSortDescriptors at
all, and we had to keep track of the user's layers of sorting demands
ourselves (not to mention keeping the roads clean with our tongues). m.
--
matt neuburg, phd = email@hidden, http://www.tidbits.com/matt/
pantes anthropoi tou eidenai oregontai phusei
AppleScript: the Definitive Guide - Second Edition!
http://www.amazon.com/gp/product/0596102119
Take Control of Word 2004, Tiger, and more -
http://www.takecontrolbooks.com/tiger-customizing.html
Subscribe to TidBITS! It's free and smart. http://www.tidbits.com/
_______________________________________________
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