swift - 哪个更有效 : Creating a "var" and re-using it, 或创建多个 "let"s？

Question

只是好奇哪个在 swift 中更高效/更好:

• 创建三个临时常量(使用 let)并使用这些常量定义其他变量
• 创建一个临时变量(使用 var)并使用该变量保存三个不同的值，这些值随后将用于定义其他变量

也许通过一个例子可以更好地解释这一点:

var one = Object()
var two = Object()
var three = Object()

func firstFunction() {
    let tempVar1 = //calculation1
    one = tempVar1

    let tempVar2 = //calculation2
    two = tempVar2

    let tempVar3 = //calculation3
    three = tempVar3

}

func seconFunction() {
    var tempVar = //calculation1
        one = tempVar

    tempVar = //calculation2
        two = tempVar

    tempVar = //calculation3
        three = tempVar

}

这两个函数哪个更高效？感谢您的宝贵时间!

Answer 1

不要太可爱，但上面代码的最有效版本是:

var one = Object()
var two = Object()
var three = Object()

这在逻辑上等同于您编写的所有代码，因为您从不使用计算结果(假设计算没有副作用)。优化器的工作就是简化为这种最简单的形式。从技术上讲，最简单的形式是:

func main() {}

但优化器并不那么聪明。但是优化器确实足够聪明，可以得到我的第一个例子。考虑这个程序:

var one = 1
var two = 2
var three = 3

func calculation1() -> Int { return 1 }
func calculation2() -> Int { return 2 }
func calculation3() -> Int { return 3 }

func firstFunction() {
    let tempVar1 = calculation1()
    one = tempVar1

    let tempVar2 = calculation2()
    two = tempVar2

    let tempVar3 = calculation3()
    three = tempVar3

}

func secondFunction() {
    var tempVar = calculation1()
        one = tempVar

    tempVar = calculation2()
        two = tempVar

    tempVar = calculation3()
        three = tempVar
}

func main() {
    firstFunction()
    secondFunction()
}

通过优化的编译器运行它:

$ swiftc -O -wmo -emit-assembly x.swift

这是整个输出:

    .section    __TEXT,__text,regular,pure_instructions
    .macosx_version_min 10, 9
    .globl  _main
    .p2align    4, 0x90
_main:
    pushq   %rbp
    movq    %rsp, %rbp
    movq    $1, __Tv1x3oneSi(%rip)
    movq    $2, __Tv1x3twoSi(%rip)
    movq    $3, __Tv1x5threeSi(%rip)
    xorl    %eax, %eax
    popq    %rbp
    retq

    .private_extern __Tv1x3oneSi
    .globl  __Tv1x3oneSi
.zerofill __DATA,__common,__Tv1x3oneSi,8,3
    .private_extern __Tv1x3twoSi
    .globl  __Tv1x3twoSi
.zerofill __DATA,__common,__Tv1x3twoSi,8,3
    .private_extern __Tv1x5threeSi
    .globl  __Tv1x5threeSi
.zerofill __DATA,__common,__Tv1x5threeSi,8,3
    .private_extern ___swift_reflection_version
    .section    __TEXT,__const
    .globl  ___swift_reflection_version
    .weak_definition    ___swift_reflection_version
    .p2align    1
___swift_reflection_version:
    .short  1

    .no_dead_strip  ___swift_reflection_version
    .linker_option "-lswiftCore"
    .linker_option "-lobjc"
    .section    __DATA,__objc_imageinfo,regular,no_dead_strip
L_OBJC_IMAGE_INFO:
    .long   0
    .long   1088

您的函数甚至在 输出中，因为它们什么都不做。 main 简化为:

_main:
    pushq   %rbp
    movq    %rsp, %rbp
    movq    $1, __Tv1x3oneSi(%rip)
    movq    $2, __Tv1x3twoSi(%rip)
    movq    $3, __Tv1x5threeSi(%rip)
    xorl    %eax, %eax
    popq    %rbp
    retq

这会将值 1、2 和 3 粘贴到全局变量中，然后退出。

我的观点是，如果它足够聪明可以做到这一点，请不要尝试用临时变量来事后猜测它。它的工作是弄清楚这一点。事实上，让我们看看它有多聪明。我们将关闭整体模块优化 (-wmo)。没有它，它不会剥离函数，因为它不知道是否有其他东西会调用它们。然后我们可以看看它是如何编写这些函数的。

这是firstFunction():

__TF1x13firstFunctionFT_T_:
    pushq   %rbp
    movq    %rsp, %rbp
    movq    $1, __Tv1x3oneSi(%rip)
    movq    $2, __Tv1x3twoSi(%rip)
    movq    $3, __Tv1x5threeSi(%rip)
    popq    %rbp
    retq

因为它可以看到计算方法只返回常量，所以它内联这些结果并将它们写入全局变量。

现在 secondFunction() 怎么样:

__TF1x14secondFunctionFT_T_:
    pushq   %rbp
    movq    %rsp, %rbp
    popq    %rbp
    jmp __TF1x13firstFunctionFT_T_

是的。太聪明了。它意识到 secondFunction() 与 firstFunction() 相同，它只是跳转到它。您的函数完全相同，优化器知道这一点。

那么什么是最有效的呢？最容易推理的那个。副作用最少的一种。最容易阅读和调试的一种。这就是您应该关注的效率。让优化器完成它的工作。它真的很聪明。你用漂亮、清晰、明显的 Swift 编写得越多，优化器就越容易完成它的工作。每次你“为了性能”做一些聪明的事情，你只是让优化器更加努力地工作来弄清楚你做了什么(并且可能撤销它)。

---

只是为了结束这个想法:您创建的局部变量几乎没有提示给编译器。当编译器将您的代码转换为它的内部表示 (IR) 时，编译器会生成它自己的 局部变量。红外在 static single assignment form (SSA)，其中每个变量只能赋值一次。因此，您的第二个函数实际上创建了比第一个函数更多的局部变量。这是函数一(使用 swiftc -emit-ir x.swift 创建):

define hidden void @_TF1x13firstFunctionFT_T_() #0 {
entry:
  %0 = call i64 @_TF1x12calculation1FT_Si()
  store i64 %0, i64* getelementptr inbounds (%Si, %Si* @_Tv1x3oneSi, i32 0, i32 0), align 8
  %1 = call i64 @_TF1x12calculation2FT_Si()
  store i64 %1, i64* getelementptr inbounds (%Si, %Si* @_Tv1x3twoSi, i32 0, i32 0), align 8
  %2 = call i64 @_TF1x12calculation3FT_Si()
  store i64 %2, i64* getelementptr inbounds (%Si, %Si* @_Tv1x5threeSi, i32 0, i32 0), align 8
  ret void
}

在这种形式中，变量有一个%前缀。如您所见，有 3 个。

这是你的第二个函数:

define hidden void @_TF1x14secondFunctionFT_T_() #0 {
entry:
  %0 = alloca %Si, align 8
  %1 = bitcast %Si* %0 to i8*
  call void @llvm.lifetime.start(i64 8, i8* %1)
  %2 = call i64 @_TF1x12calculation1FT_Si()
  %._value = getelementptr inbounds %Si, %Si* %0, i32 0, i32 0
  store i64 %2, i64* %._value, align 8
  store i64 %2, i64* getelementptr inbounds (%Si, %Si* @_Tv1x3oneSi, i32 0, i32 0), align 8
  %3 = call i64 @_TF1x12calculation2FT_Si()
  %._value1 = getelementptr inbounds %Si, %Si* %0, i32 0, i32 0
  store i64 %3, i64* %._value1, align 8
  store i64 %3, i64* getelementptr inbounds (%Si, %Si* @_Tv1x3twoSi, i32 0, i32 0), align 8
  %4 = call i64 @_TF1x12calculation3FT_Si()
  %._value2 = getelementptr inbounds %Si, %Si* %0, i32 0, i32 0
  store i64 %4, i64* %._value2, align 8
  store i64 %4, i64* getelementptr inbounds (%Si, %Si* @_Tv1x5threeSi, i32 0, i32 0), align 8
  %5 = bitcast %Si* %0 to i8*
  call void @llvm.lifetime.end(i64 8, i8* %5)
  ret void
}

这个有 6 个局部变量!但是，就像原始源代码中的局部变量一样，这并没有告诉我们最终的性能。编译器之所以创建这个版本，是因为它比变量可以更改其值的版本更容易推理(因此更容易优化)。

(更引人注目的是 SIL 中的这段代码 (-emit-sil)，它为函数 1 创建了 16 个局部变量，为函数 2 创建了 17 个局部变量!如果编译器乐于发明 16局部变量只是为了让它更容易推理大约 6 行代码，你当然不应该担心你创建的局部变量。它们不仅仅是一个小问题；它们是完全免费的。)