在遍歷 string 字符時發(fā)現(xiàn)函數(shù)執(zhí)行時間超出預(yù)期，通過 Time Profile 檢查遣鼓，發(fā)現(xiàn)主要耗時在于 String.index(after:)上。
image.png
由于原函數(shù)內(nèi)容較多，所以構(gòu)建小型測試代碼來分析具體耗時澜公，測試基準為長度一萬的字符串 bigT
image.png
可以看出對于不需要進行 index 訪問的場景冕末，直接 (for char in bigT)的遍歷是最快的
而對于需要進行 index 訪問的場景萍歉，就要特別注意了。筆者正是由于忽略了String.count的O(n)成本档桃，導(dǎo)致的耗時問題枪孩。
image.png
從上圖可以看到如果邊界條件用的是 String.count，時間就百倍于 Array.count 了
原因正是在于String.count是計算屬性（computed property ）而非存儲屬性（stored property）藻肄，所以用在邊界處理時蔑舞，每一次循環(huán)都會進行計算。
文檔也沒說一聲
image.png
得出結(jié)論：
- String.count是 O(n)復(fù)雜度的計算變量仅炊，不要用在邊界判斷處斗幼。
參考資料
count | Apple Developer Documentation
Simpler String slicing in Swift 4
String.count: computed vs. stored property - Evolution / Discussion - Swift Forums
