Swift implementation and comparison of sorted methods

Swift has excellent functional programming skills, and interviewers like to ask us for quick sorting when interviewing, so how do you make a quick order with Swift? First extend the array class:

Array {    var decompose : (head: T, tail: [T])? {        return0) ? (self[0Array(self[1..<count])) : nil    }}

The function of the decompose property is to return the first element and the remaining elements in the array, noting that the property is selectable, and when count is 0 returns Nil,count is the property of the array. The reason for using extensions is that this split can achieve very many operations, once and for all.
Then implement a quick Sort method:

func qsortdemo->  [int] {if  let  (pivot, rest) = input.decompose {let  lesser = rest.fi lter {$0  < pivot} let  greater = Rest.filte R {$0  >= Pivot} return  Qsortdemo (Lesser) +  [Pivot] + Qsortdemo (Greater)} else  {return  []    }}

You can see that code that uses Swift for quick sorting is very concise. First call the Decompose property of the sequence to be sorted, use a tuple to hold the first element of the array, and the first array, as it is still recursive, using optional bindings for boundary judgments. The filter method is used inside the optional binding to split the elements, eliminating the complexity of comparing moving elements, the resulting lesser is smaller than the pivot array, the greater is larger than the pivot array, the concatenation of the array is used on the return, and the split array is recursive, the structure is very simple , the process of a quick sort is over.
Let's do a performance test in storyboard:

a:[Int] = [1,2,4,6,2,4,3,7,8]qsortDemo(a)

The efficiency of array A in the quick row is as follows:

You can see that the return in the optional binding executes 9 times the number of elements in a, as expected, because each element determines its position in this return, so the number of executions should be n. So why did the statement in else execute n+1 times? To know what happens to each element in a single recursion, you can simulate a recursive occurrence with only one element in a, as follows:

opens the execution record for decompose:

can see that decompose was executed three times, the first time being [1] To access, return ([1],[]), at this time in the optional binding, lesser and greater are [], in return, lesser and greater will continue to access decompose at this time returned two nil, So the corresponding optional binding is judged to be return[in the false direct run else, and the entire process is complete. The
Else condition returns a value that is returned by the [],[] join to the array, so it can be returned as a boundary. The
expands the elements in a to two. The execution record in

Decompose is:

Well understood, the first split gets [1] and [2],pivot for [1],lesser], and greater to [2]. At return, lesser access decompose get nil, optional binding is false execution else in the statement, at this time greater is an array of elements, the same step as above. So the lesser and greater of the last element at the same time in this quick-row recursion are [], and the other elements have only one side for [], which explains why the return occurs n+1 execution times.
Look at the two filter, this split method requires extra space to save lesser and greater, point-tracking can be seen in lesser and greater tracking track is the opposite, it is well understood. In addition, the filter is the system API, do not know the internal implementation method, but can be seen in the judgment [2] The element in the time of the call three times, should be related to the internal mechanism, although it seems to be executed more times, but eliminates the traditional fast sort of the element exchange position operation, the efficiency is not to say. In short write so many final effects on one: sort.
After reading this code, I thought: since it is a sort, then it is necessary to use the sorted method of the system (the previous Sort method), how does the effect? Let's try the first example with just one line of code:

let b = a.sorted{$0<$1}

What's the effect? Please see:

Yes, the whole method only compares 15 times! The efficiency is amazing, the sorted is implemented by Apple engineers at the bottom, and I think they must have a good way to improve efficiency. Don't believe me? To take a look at the example below, we all know that the worst case scenario for a fast sort occurs at recursion when the array is unbalanced, for example, by modifying the arrays A to:

var a:[Int] = [1,1,1,1,1,1,1,1,1]

The overall size of the array has not changed and the efficiency of the operation

It can be seen that the main time-consuming part of the algorithm lesser and greater execution at this time from the previous 35 times changed to 45 times, then the sorted method of the implementation of the efficiency?

You're not mistaken! For the order array with the most headaches in the sorted, the number of repetitions is only n times! It is indicated that the sorted method is directly output when confronted with this type of array. Of course, the statement in the closure must be appropriate, "do not use the equals sign!" ", such as rewriting a:

var a:[Int] = [1,1,2,2,3,1,1,1,1]

If there is no equal number case:

If you write the equals sign:

omg! the same effect under the premise of a lot of poor efficiency.
Another extreme case in which an array is reversed in reverse order:

Of course, the time of the queue is the same as the exact same element:

If you feel that the magnitude is too small to be enjoyable, then a large array:
Now modify a to 500 random positive integers within 100:

a:[UInt32] = []forin0..<500{  a100)}

Compare two sorting methods at the same time, the following is a quick line:

Here is the efficiency of the sorted:

You can try, the larger the size of the array efficiency difference is more obvious, sorted with the visual speed of the second kill the fast platoon!
Where's the applause?

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

Swift implementation and comparison of sorted methods