A very fast sortUsingDescriptors:

[mrcarlberg]

I needed to sort a lot of objects and was not impressed by the speed.
Sharing my improvements...

[primalmotion]

Do you have any performance improvement ratio?

[cappbot]

Milestone: Someday. Label: #new. What's next? A reviewer should examine this issue.

[mrcarlberg]

It's around factor 4 when running the performance test cases from command line or Safari. Running a table view with 21000+ objects and sorting by clicking on column header it is a factor 2. But I guess that the table view might do other stuff then sorting.....

[aparajita]

We really need a unit test for this.

[mrcarlberg]

Please let me know what you need for type of unit tests? There are already some in CPArrayPerformanceTest.j and CPArrayControllerPerformance.j

[aparajita]

Then it would be nice if you could make an app that shows the performance figures for old and new code.

[mrcarlberg]

Ok, I created an ugly test Application :)

Source Code (.tgz)

[cacaodev]

It's definitely faster ! While testing with the current ojunit test, i noticed the native sort testing was wrong because it was not using sort descriptors. I fixed this and added tests for random numeric and text arrays.

#1562

[primalmotion]

Awesome work! Any objection before merging it in?

[aparajita]

It is definitely way faster than the current Cappuccino sort, but overall not faster than native sort. Is there a reason native sorting can't be used?

[mrcarlberg]

I think native javascript sorting is not stable. It will not preserve order if elements are the same. I guess Cocoa has stable sorting. This can be a reason not to use native sorting in Cappuccino.

[mrcarlberg]

I found a bug. I'm not using the selector in the sort descriptor. Using compare: all the time....
I'll make some modifications and add a test case for that.....

[aparajita]

Please be sure you are testing all possible permutations of CPSortDescriptor.

[aparajita]

Here and everywhere else, please separate all control structures (and their bracketed code blocks) from surrounding code with a blank line.

[cacaodev]

@aparajita
In the current test, native sort is using js code instead of capp code for sort descriptors and it appears faster than it is. see my modified CPArrayPerformanceTest above.

[aljungberg]

I'm going to merge #1562 first, then we can look into this in more detail.

milestone=0.9.6
+feature
+Foundation
+#acknowledged

[cappbot]

Milestone: 0.9.6. Labels: #acknowledged, Foundation, feature. What's next? A reviewer should examine this issue.

[aljungberg]

So in my testing this is much faster.

Interestingly sort using selector also became faster. I did some testing and this seems to be caused by the minor change of declaring sortArrayUsingFunction as an independent function instead of declaring it in the scope of sortUsingFunction:. I'm guessing that the independent function might be avoiding the with() penalty.

In all cases except "TEXT RANDOM" with selector, the non-native version is faster than the native version in ojtest. (This is likely to stop being the case when we don't use with() anymore. Native should be faster, at least if we also cache the valueForKey: responses in the native version like this hand coded algorithm does.)

[aljungberg]

It also seems like the Safari based application is showing pretty random results. If I click on Run I can get some results randomly 10X larger than other results. ojtest based testing seems to give much more reliable results. Maybe this is because Safari is interrupting the non-native sort more often to do other things when you have many tabs open, and those interruptions are random in frequency and length.

[aljungberg]

Great work, thanks!

+#fixed

[cappbot]

Milestone: 0.9.6. Labels: #fixed, Foundation, feature. What's next? This issue is considered successfully resolved.

[aljungberg]

For future reference, here are my timing results using ojtest on a 2011 MacBook Pro. It's an average of 3 runs before and after, testing both sort using descriptors and sort using selectors while comparing them against native sort using the code in #1562.

[klaaspieter]

I know this has been merged already, but we might want to make this function more readable. All the one letter variable names are very hard to translate to a meaning and this function will be very hard to maintain for everybody that hasn't written it and even for the original author 3 months from now.

[aparajita]

I agree completely. Maybe the original author would be kind enough to make it more readable.

[cacaodev]

i'm the one who submitted the merge-sort function and it's a port from C. I can't find the original source right now but i'll keep searching.

[aparajita]

it's a port from C

That was obvious. ;-)