|
Cocoa編程的一個通常的任務是要去循環遍歷一個對象的集合 (例如,一個 NSArray, NSSet 或者是 NSDictionary). 這個看似簡單的問題有廣泛數量的解決方案,它們中的許多不乏有對性能方面問題的細微考慮. 對於速度的追求首先,是一個免責聲明: 相比其它問題而言,一個 Objective-C 方法原始的速度是你在編程時最后才需要考慮的問題之一 – 區別就在於這個問題夠不上去同其它更加需要重點考慮的問題進行比較,比如說代碼的清晰度和可讀性. 但速度的次要性並不妨礙我們去理解它. 你應該經常去了解一下性能方面的考慮將如何對你正在編寫的代碼產生影響,一邊在極少數發生問題的情況下,你會知道如何下手. 還有,在循環的場景中,大多數時候不管是從可讀性或者是清晰度考慮,你選擇哪種技術都沒什么關系的, 所以你還不如選擇速度最快的那一種. 沒有必要選擇編碼速度比要求更慢的。 |
leoxu
|
|
考慮到這一點,就有了如下的選擇:
經典的循環方式
這是循環遍歷一個數組的一個簡單熟悉的方式; 從性能方面考慮它也相當的差勁. 這段代碼最大的問題就是循環每進行一次我們都會調用數組的計數方法. 數組的總數是不會改變的,因此每次都去調用一下這種做法是多余的. 像這種代碼一般C編譯器一般都會優化掉, 但是 Objective-C 的動態語言特性意味着對這個方法的調用不會被自動優化掉. 因此,為了提升性能,值得我們在循環開始之前,將這個總數存到一個變量中,像這樣:
|
leoxu
|
NSEnumeratorNSEnumerator 是循環遍歷集合的一種可選方式. 所有的集合都已一個或者更多個枚舉方法,每次它們被調用的時候都會返回一個NSEnumerator實體. 一個給定的 NSEnumerator 會包含一個指向集合中第一個對象的指針, 並且會有一個 nextObject 方法返回當前的對象並對指針進行增長. 你可以重復調用它直到它返回nil,這表明已經到了集合的末尾了:
NSEnumerator 的性能可以媲美原生的for循環, 但它更加實用,因為它對索引的概念進行了抽象,這意味着它應用在結構化數據上,比如鏈表,或者甚至是無窮序列和數據流,這些結構中的數據條數未知或者並沒有被定義. |
leoxu
|
快速枚舉快速枚舉是在 Objective-C 2.0 中作為傳統的NSEnumerator的更便利(並且明顯更快速) 的替代方法而引入的. 它並沒有使得枚舉類過時因為其仍然被應用於注入反向枚舉, 或者是當你需要對集合進行變更操作 (之后會更多地提到) 這些場景中. 快速枚舉添加了一個看起來像下面這樣子的新的枚舉方法:
如果你正在想着“那看起來並不怎么舒服啊!”, 我不會怪你的. 但是新的方法順便帶來了一種新的循環語法, for…in 循環. 這是在幕后使用了新的枚舉方法, 並且重要的是在語法和性能上都比使用傳統的for循環或者 NSEnumerator 方法都更省心了:
|
leoxu
|
||||||
| 其它翻譯版本(1) |
枚舉塊隨着塊的誕生,Apple加入第四個基於塊語法的枚舉機制. 這無疑比快速枚舉更加的少見, 但是有一個優勢就是對象和索引都會返回, 而其他的枚舉方法只會返回對象. 枚舉塊的另外一個關鍵特性就是可選擇型的並發枚舉 (在幾個並發的線程中枚舉對象). 這不是經常有用,取決於你在自己的循環中具體要做些什么, 但是在你正有許多工作要做,並且你並不怎么關心枚舉順序的場景下,它在多核處理器上可能會產生顯著的性能提高 (現在所有的 Mac和iOS設備都已經有了多核處理器). |
leoxu
|
基准測試那么這些方法疊加起來會如何呢, 性能會更加的好么? 這里有一個簡單的基准測試命令行應用,比較了使用多種不同方法枚舉一個數據的性能. 我們已經在 ARC 關閉的情況下運行了它,以排除任何干擾最終結果的隱藏在幕后的保留或者排除處理. 由於是運行在一個很快的 Mac 機上面, 所有這些方法運行極快以至於我們實際上不得不使用一個存有10,000,000 (一千萬) 對象的數組來測量結果. 如果你決定在一個 iPhone 進行測試, 最明智的做法是使用一個小得多的數量! 為了編譯這段代碼:
下面展示出了結果:
|
leoxu
|
|
忽略掉時間的具體長短. 我們感興趣的是它們同其它方法比較的相對大小. 如果我們按順序排列它們,快的放前面,我會得到了下面的結果:
For…in 是勝出者. 顯然他們將其稱為快速枚舉是有原因的! 並發枚舉看起來是比單線程的快一點點, 但是你沒必要對其做更多的解讀: 我們這里是在枚舉一個非常非常大型的對象數組,而對於小一些的數據並發執行的開銷遠多於其帶來的好處. 並發執行的主要是在當你的循環需要大量的執行時間時有優勢. 如果你在自己的循環中有許多東西要運行,那就考慮試下並行枚舉,在你不關心枚舉順序的前提下 (但是請用行動的去權衡一下它是否變得更快樂,不要空手去揣度). |
leoxu
|
其它集合類型Other Collection Types那么其它的結合類型怎么樣呢, 比如 NSSet 和 NSDictionary? NSSet 是無序的, 因此沒有按索引去取對象的概念.我們也可以進行一下基准測試:
結果同 NSArray 一致; for…in 再一次勝出了. NSDictionary怎么樣了? NSDictionary 有一點不同因為我們同時又一個鍵和值對象需要迭代. 在一個字典中單獨迭代鍵或者值是可以的, 但典型的情況下我們兩者都需要. 這里我們有一段適配於操作NSDictionary的基准測試代碼:
|
leoxu
|
|
NSDictionary 填充起來比 NSArray 或者 NSSet 慢得多, 因此我們把數據條數減少到了10,000 (一萬) 以避免機器鎖住. 因而你應該忽略結果怎么會比那些 NSArray 低那么多,因為我們使用的是更少對象的 1000 次循環:
沒有優化過的循環再這里慢得很壯觀,因為每一次我們都復制了鍵數組. 通過把鍵數組和總數存到變量中,我們獲得了更快的速度. 查找對象的消耗現在主宰了其它的因素,因此使用一個for循環, NSEnumerator 或者for…in 差別很小. 但是對於枚舉塊方法而言,它在一個方法中把鍵和值都返回了,所以現在變成了最快的選擇。 |
leoxu
|
反轉齒輪基於我們所見,如果所有其它的因素都一樣的話,在循環遍歷數組時你應該嘗試去使用for...in循環, 而遍歷字典時,則應該選擇枚舉塊. 也有一些場景下這樣的做法並不可能行得通,比如我們需要回頭來進行枚舉,或者當我們在遍歷時想要變更集合的情況. 為了回過頭來枚舉一個數據,我們可以調用reverseObjectEnumerator方法來獲得一個NSEnumerator 以從尾至頭遍歷數組. NSEnumerator, 就像是 NSArray 它自己, 支持快速的枚舉協議. 那就意味着我們仍然可以在這種方式下使用 for…in, 而無速度和簡潔方面的損失:
(除非你異想天開, NSSet 或者 NSDictionary 是沒有等效的方法的, 而反向枚舉一個 NSSet 或者NSDictionary無論如何都沒啥意義, 因為鍵是無序的.) 如果你想使用枚舉塊的話, NSEnumerationReverse你可以試試, 像這樣:
|
leoxu
|
變更Mutation應用同樣的循環技術到變更中的集合上是可能的; 其性能也大致相同. 然而當你嘗試在循環數組或者字典的時候修改它們,你可能經常會面臨這樣的異常: '*** Collection XYZ was mutated while being enumerated.'
就像我們優化了的for循環, 所有這些循環技術的性能取決於事先把數據總數存下來,這意味着如果你開始在循環中間加入或者去掉一個數據時,這個數據就不正確了. 但是在循環進行中加入,替換或者移除一條數據時經常想要做的事情. 那么什么才是這個問題的解決之道呢? 我們經典的for循環可以工作得很好,因為它不依賴於駐留的總數常量; 我們只需要記得,如果我們添加或者移除了一條數據,就要增加或者減小索引. 但我們已經了解到for循環並不是一種速度快的解決方案. 我們優化過的for循環則是一個合理的選擇, 只要我們記得按需遞增或者遞減技術變量,還有索引. |
leoxu
|
|
我們仍然可以使用for…in, 但前提是我們首先創建了一個數組的拷貝. 這會起作用的,例如:
如果我們對不同的技術進行基准測試(必要時把復制數組的開銷算在內,以便我們可以對原來數組內的數據進行變更), 我們發現復制抵消了 for…in 循環之前所擁有的好處: $ For loop: 0.111422 $ Optimized for loop: 0.08967 $ Enumerator: 0.313182 $ For…in loop: 0.203722 $ Enumeration block: 0.436741 $ Concurrent enumeration block: 0.388509
在我們遍歷一個數組時修改這個數組最快的計數,似乎是需要使用一個優化了的for循環的. 對於一個 NSDictionary, 我們不需要為了使用NSEnumerator 或者快速枚舉而復制整個字典; 我們可以只去使用allKeys方法獲取到所有鍵的一個副本. 這都將能很好的運作起來:
|
leoxu
|
|
然而同樣的技術在使用enumerateKeysAndObjectsUsingBlock方法時並不能起作用. 如果我們循環遍歷一個字典進行基准測試, 按照需要對鍵或者對字典整體創建備份,我們得到了下面的結果: $ For loop: 2.24597 $ Optimized for loop: 0.00282001 $ Enumerator: 0.00508499 $ For…in loop: 0.000990987 $ Enumeration block: 0.00144804 $ Concurrent enumeration block: 0.00166804
這里我們可以看到 for…in 循環是最快的一個. 那是因為在for...in循環中根據鍵取對象的開銷現在已經被在調用枚舉塊方法之前復制字典的開銷蓋過去了. |
leoxu
|
|
當枚舉一個NSArray的時候:
當枚舉一個NSSet的時候:
當枚舉一個NSDictionary的時候:
這些方法可能不是最快的,但他們都是非常清晰易讀的。所以請記住,有時是在不寫干凈的代碼,和快速的代碼之間做出選擇,你會發現,你可以在兩個世界得到最好的。 |

