Re: sort descriptor optimization
Re: sort descriptor optimization
- Subject: Re: sort descriptor optimization
- From: "Adam R. Maxwell" <email@hidden>
- Date: Tue, 4 Jul 2006 17:16:18 -0700
On Jul 4, 2006, at 16:44, Matt Neuburg wrote:
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.
Possible, but I'm still not sure nil would be handled as we desire
(I've forgotten the details, but there was a reason we did it this
way). Also, the existing code has been debugged, and it's working
well, if slowly.
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.
We have user-defined keys, and not all of them are in a dictionary at
any given time (and vary otherwise as well). As I said, this is not
an option, and it's deeply ingrained in code that's several years
old. Although I'm not interested in rewriting our object model to
use NSNull, your suggestion is useful to someone starting from scratch.
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.
Since when is subclassing unusual? If NSSortDescriptor is supposed
to be opaque, then compareObject:toObject: should have been a private
method.
I'm not "complaining that it doesn't work," since it does work. As
my subject indicates, I'm asking a question about optimizing code, so
let's just suppose that I have a valid reason to do this. Apple
appears to be doing some interesting tricks with NSArray sorts when
using NSSortDescriptor, and I think it's reasonable that they apply
some optimization to using a subclass (maybe IMP caching of
compareObject:toObject:).
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.
Yeah, I know; we were using sortUsingFunction:context: until we
dropped Jaguar support. The main reason we switched to
NSSortDescriptors is that we can subsort using an array of
descriptors. Since we support arbitrary user-configurable table
columns, our sorting code has always been a bit hairy.
-- Adam
_______________________________________________
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