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

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

推荐阅读更多精彩内容