为什么 for-in 比在快速 Debug模式下慢?
如果您认为,是的,它是在 中运行的无优化 .
⬇️下面的代码,Time 是比较 for-in 和 while in 没有优化
49999995000000
换入 -- 时间 = 3.3352
4999999950000000
而 -- 时间 = 0.3613
⬇️但是,如果使用 速度优化
49999995000000
for-in -- 时间 = 0.0037
49999995000000
而 -- 时间 = 0.0035
我想知道“为什么 for-in 比没有优化时慢?为什么 for-in 和 while 优化这么快?”
import Foundation
func processTime(_ title: String, blockFunction: () -> ()) {
print()
let startTime = CFAbsoluteTimeGetCurrent()
blockFunction()
let processTime = CFAbsoluteTimeGetCurrent() - startTime
print(title, " -- time = \(String(format : "%.4f",processTime))")
}
processTime("for-in") {
var sum = 0
for i in 0..<10000000 {
sum += i
}
print(sum)
}
processTime("while") {
var sum = 0
var i = 0
while i<10000000 {
sum += i
i += 1
}
print(sum)
}
最佳答案
从 Swift 的角度来看,您的 for
循环实际上翻译成这样的:
let range = 0..<10000000
var iterator = range.makeIterator()
while let next = iterator.next() {
...
}
请注意,有很多电话是对 next
的。在范围的迭代器上,它有自己的状态,必须跟踪,IndexingIterator.next
调用一堆协议(protocol)方法,调度也需要一些时间,因为它必须查找见证表。看看究竟什么叫 Iterator.next
将要制作here .如果您处于 Debug模式,那么这些都不会被优化。
将其与您的 while 循环进行比较,该循环基本上将某些内容设置为 0,比较,执行循环中的操作,将其加 1,然后重复。显然,这比调用所有这些方法要简单得多。
但是,如果您启用优化,编译器可以看到 for 循环正在执行 while 循环所做的事情。
因为我觉得它很有趣,所以我做了一些循环的时间分析,例如:
var s = ""
for i in 0...10000000 {
s += "\(i)"
}
80% 的时间花在
next()
上,看看它做了多少事情!我的截图甚至不能包含所有内容。字符串连接只占 6% 左右(截图中没有)。
关于swift - 为什么 for-in 比在快速 Debug模式下慢?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/67021110/