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