O(n)的String.count

在遍历 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