哪个更有效：创建一个“var”并重新使用它，还是创建几个“let”？

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) 时会生成自己的局部变量。IR 采用静态单赋值形式（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 行代码，你当然不应该担心你创建的局部变量。它们不仅仅是一个小问题；它们是完全免费的。）