TL.DR

软件是一个巨大的有限状态机。工程师日常做的bug修复、性能调优，本质上就是尽可能保证代码处于有序状态下。

状态总数少了，错误就少了，性能也就提升了。

Case 1：OC Runtime的

这个例子的关键点是性能。

OC为了做到ABI兼容，改变了C、C++以来对象的内存结构，每个成员变量都需要两次寻址才能访问到。比如要获取obj的第n个变量的偏移地址，就要

*((&obj->isa.cls->data()->ro->ivars->first)[N]->offset);

看起来就慢爆了。

在实现上，LLVM为每个类的每个成员变量都分配了一个全局变量，用于存储该成员变量的偏移值。这样，访问每个变量需要两次寻址，先获取全局变量，再取全局变量的值作为地址找到真正的变量。

编译后的

obj->myInt = 42;

对应于如下的简单C语言代码

int32_t g_ivar_MyClass_myInt = 40;  // 全局变量*(int32_t *)((uint8_t *)obj + g_ivar_MyClass_myInt) = 42;

这就是为什么ivar_t.offset用int指针来存储偏移值，而不是直接放一个int的原因。

struct ivar_t {    int32_t *offset;  //注意，这里是指针    const char *name;    const char *type;        //...}

真正存放偏移值的地址是固定不变的，在编译时就确定了下来。因此才能用区区2条指令搞定动态布局的成员变量。

Case 2：矩阵相乘

这个例子的关键点是减少错误。

如图所示，要保证第一个矩阵中的列数必须与第二个矩阵中的行数相同。简单的做法是做运行时检查

struct Matrix {  let rows: Int  let columns: Int}func multiply(m1: Matrix, _ m2: Matrix) -> Matrix? {  // do the matrices have the correct sizes?  precondition(m1.columns == m2.rows)    // bunch of math...}

更好的做法是在编码时，就不允许出现行列不等的情况

protocol Dimension {  static var size: Int { get set }}func multiply
    
                  (m1: Matrix
     
      , _ m2: Matrix
      
       ) -> Matrix
       
         {  // bunch of math...  return Matrix
        
         ()}
        
       
      
     
    

运行结果

struct NumExamples: Dimension { static var size = 20 }struct NumFeatures: Dimension { static var size = 10 }struct OneDimensional: Dimension { static var size = 1 }let A = Matrix
    
     ()let B = Matrix
     
      ()let C = multiply(A, B)   // yay!let D = multiply(B, A)   // compiler error
     
    

完整的优化过程不在本文的讨论范围内，感兴趣的可以看 。

参考链接