Swift的演员阵容的运行时成本是多少？

Question

以下类型转换会产生哪些不同的运行时成本？

1. 恒定的数字转换,例如:

   let f = 0.1 as CGFloat
   

   我想这个运行时成本为零.

2. 运行时值的数字转换,例如:

   let f = someDoubleValue as CGFloat
   

   我想这会有非常小的运行时成本.

3. 向上,例如:

   let dict: [String: Int] = ...
   let anyObj = dict as AnyObject
   

   我希望这个运行时成本为零.

4. 可用的Downcast,例如:

   let anyObj: AnyObject = ...
   if let str = anyObj as? String { ... }
   

   我希望它的运行时成本与动态类型的层次结构中的类数成比例anyObj.

5. 强制向下倾斜,例如:

   let anyObj: AnyObject = ...
   let str = anyObj as! String
   

   也许强迫低价的成本略低？

6. 强迫收集下来,例如:

   let dates: [AnyObject] = ...
   for date in dates as! [NSDate] { ... }
   

   这里发生了什么 - 尤其dates是来自一个NSArray？此演员的运行时成本是否与其元素的数量成比例？如果我转换为更复杂的集合类型[String: [String: [Int]]]- 如果整个集合遍历以确保其所有元素和子元素符合此演员表,该怎么办？

对于前四种情况中的每一种情况,我的断言都是真的吗？

Answer 1

• 如果它显然是可铸造的(如数字铸造和向上铸造),则为O(1)(几乎为0):情况1,2,3.

• 对于其他非收集铸件,显然是O(1):情况4,5.

• 对于收集低估:

  • as? 是O(n),因为热切地执行元素类型检查.
  • 本机强制向下转换是O(1)因为元素类型检查是延迟的:情况6.
  • 桥接强制downcasting(NSArray as! [NSDate])是O(n)因为要素元素类型检查是急切执行的.
  • 嵌套集合以递归方式呈现,因此您只需递归应用上述规则.

资料来源:

1. https://github.com/apple/swift/blob/master/stdlib/public/runtime/Casting.cpp
2. https://github.com/apple/swift/blob/master/stdlib/public/core/ArrayCast.swift
3. https://github.com/apple/swift/blob/master/stdlib/public/core/HashedCollections.swift.gyb