測試了一下LINQ寫的Quick Sort效能

2021-09-07 22:26:54 字數 1344 閱讀 9341

昨晚看到乙個帖子, 說的是三行**實現快速排序, 文中實現quick sort**如下:

public static 

ienumerable

quicksort(ienumerable

list) where t : icomparable

不由想起老趙兩年前(正好整整兩年傳統的的quick sort演算法摘自維基百科:

public static void sort(int numbers)

private static void sort(int numbers, int left, int right)

sort(numbers, left, i - 1);

sort(numbers, j + 1, right);

}}private static void swap(int numbers, int i, int j)

由於codetimer最後乙個引數是乙個action委託, 我對兩種快速排序演算法包裝了一下, 然後測試的時候就執行這兩個方法:

public static void functionalquicksort()

; quicksort(array);

}public static void normalquicksort()

; sort(array);

}

呼叫codetimer的time方法, 就可以得到效能資料:

//引數分別為: 輸出的方法名字, 方法執行次數, 方法體

codetimer.time("functional quick sort", 10000, () => functionalquicksort());

codetimer.time("normal quick sort", 10000, () => normalquicksort());

做了幾次測試, 得到的測試資料基本上是這個情況:

這還只是7個資料的排序, 如果資料越多, 用linq寫出來的演算法效能劣勢就越明顯.

步驟序列ij

049 38 65 97 76 13 2706

149 38 65 97 76 13 2706

227 38 65 97 76 13 4926

327 38 49 97 76 13 6525

427 38 13 97 76 49 6535

527 38 13 49 76 97 6532

由此看來, 一方面是簡潔的書寫**, 另一方面是效能的考量, 您會選擇哪種呢?

測試了一下LINQ寫的Quick Sort效能

昨晚看到乙個帖子,說的是三行 實現快速排序,文中實現quick sort 如下 public static ienumerable quicksort ienumerable list where t icomparable 不由想起老趙兩年前 正好整整兩年 的乙個帖子 趣味程式設計 函式式鍊錶的快...

iOS FMDB小試了一下

今天從早上9點,一直在看fmdb,知道中午11 40。我的效率是不是很低下。中間也碰到了幾個小bug。雖然做了乙個小demo,但是覺得還比不上在專案中使用中鍛鍊的多,先暫且一總結。引入到專案中 新增庫 新建專案,開始使用 下面我們就一條條地說 fmdb裡面的 fmdb 引入到專案中,其他的可以不要 ...

昨天和今天看了linq,寫一下思路?

無語,我看網上的教程都是2007的了 我今天才開始讀,沒錯,我在上學的時候還在看泛型 錯了,上課那些根本不是泛型 天啊,進正題吧!linq 走不掉的就是2.0時代就有的匿名delegate.lamba表示式是一種語法,生成的il和匿名delegate是一樣的。不知有沒有錯 這個是原型吧 其中有協變和...