哪个更有效：创建一个 "var" 并重新使用它，还是创建多个 "let"？
Which is more efficient: Creating a "var" and re-using it, or creating several "let"s?
只是好奇 swift 中哪个 efficient/better:
- 创建三个临时常量（使用 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
}
这两个函数哪个更有效率？感谢您的宝贵时间！
除非您处理的是非常专业的用例，否则这永远不会产生有意义的性能差异。
编译器很可能可以轻松地将事情简化为 firstFunction 中的直接赋值，我不确定 secondFunction 是否可以轻松地进行类似的编译器优化。您要么必须是编译器方面的专家，要么进行一些性能测试以找出任何差异。
无论如何，除非您以数十万或数百万的规模进行此操作，否则无需担心。
我个人认为以 secondFunction 的方式重复使用变量会造成不必要的混淆，但对每个人来说都是如此。
注意：看起来你正在处理 类，但请注意 struct 复制语义意味着重新使用变量无论如何都是无用的.
你真的应该只内联局部变量：
var one: Object
var two: Object
var three: Object
func firstFunction() {
one = //calculation1
two = //calculation2
three = //calculation3
}
一个例外是如果你最终写了这样的东西：
var someOptional: Foo?
func init() {
self.someOptional = Foo()
self.someOptional?.a = a
self.someOptional?.b = b
self.someOptional?.c = c
}
在这种情况下最好这样做：
func init() {
let foo = Foo()
foo.a = a
foo.b = b
foo.c = c
self.someOptional = foo
}
或者也许：
func init() {
self.someOptional = {
let foo = Foo()
foo.a = a
foo.b = b
foo.c = c
return foo
}()
}
不要太可爱，但上面代码的最有效版本是：
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 , __Tv1x3oneSi(%rip)
movq , __Tv1x3twoSi(%rip)
movq , __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 , __Tv1x3oneSi(%rip)
movq , __Tv1x3twoSi(%rip)
movq , __Tv1x5threeSi(%rip)
xorl %eax, %eax
popq %rbp
retq
这会将值 1、2 和 3 粘贴到全局变量中，然后退出。
我的观点是，如果它足够聪明可以做到这一点，请不要尝试用临时变量来事后猜测它。它的工作是弄清楚这一点。事实上，让我们看看它有多聪明。我们将关闭整个模块优化 (-wmo)。没有它，它不会剥离函数，因为它不知道是否有其他东西会调用它们。然后我们可以看看它是怎么写这些函数的。
这是firstFunction()：
__TF1x13firstFunctionFT_T_:
pushq %rbp
movq %rsp, %rbp
movq , __Tv1x3oneSi(%rip)
movq , __Tv1x3twoSi(%rip)
movq , __Tv1x5threeSi(%rip)
popq %rbp
retq
因为它可以看到计算方法只是 return 个常量，所以它内联这些结果并将它们写入全局变量。
现在 secondFunction():
__TF1x14secondFunctionFT_T_:
pushq %rbp
movq %rsp, %rbp
popq %rbp
jmp __TF1x13firstFunctionFT_T_
是的。太聪明了。它意识到 secondFunction() 与 firstFunction() 相同，并且它只是跳转到它。您的函数完全相同，优化器知道这一点。
那么什么是最有效的呢？最容易推理的那个。副作用最少的一种。最容易阅读和调试的一种。这就是您应该关注的效率。让优化器完成它的工作。它真的很聪明。你写的越漂亮、清晰、明显 Swift，优化器就越容易完成它的工作。每次你做一些聪明的事情 "for performance," 你只是让优化器更努力地工作来弄清楚你做了什么（并且可能撤销它）。
只是为了结束这个想法：您创建的局部变量几乎没有提示给编译器。编译器在将您的代码转换为其内部表示 (IR) 时生成其 own 局部变量。 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 行代码，你当然不应该担心你创建的局部变量。它们不仅仅是一个小问题；它们是完全免费的。）
只是好奇 swift 中哪个 efficient/better:
- 创建三个临时常量（使用 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
}
这两个函数哪个更有效率？感谢您的宝贵时间！
除非您处理的是非常专业的用例，否则这永远不会产生有意义的性能差异。
编译器很可能可以轻松地将事情简化为 firstFunction 中的直接赋值，我不确定 secondFunction 是否可以轻松地进行类似的编译器优化。您要么必须是编译器方面的专家，要么进行一些性能测试以找出任何差异。
无论如何，除非您以数十万或数百万的规模进行此操作，否则无需担心。
我个人认为以 secondFunction 的方式重复使用变量会造成不必要的混淆，但对每个人来说都是如此。
注意：看起来你正在处理 类，但请注意 struct 复制语义意味着重新使用变量无论如何都是无用的.
你真的应该只内联局部变量：
var one: Object
var two: Object
var three: Object
func firstFunction() {
one = //calculation1
two = //calculation2
three = //calculation3
}
一个例外是如果你最终写了这样的东西：
var someOptional: Foo?
func init() {
self.someOptional = Foo()
self.someOptional?.a = a
self.someOptional?.b = b
self.someOptional?.c = c
}
在这种情况下最好这样做：
func init() {
let foo = Foo()
foo.a = a
foo.b = b
foo.c = c
self.someOptional = foo
}
或者也许：
func init() {
self.someOptional = {
let foo = Foo()
foo.a = a
foo.b = b
foo.c = c
return foo
}()
}
不要太可爱，但上面代码的最有效版本是：
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 , __Tv1x3oneSi(%rip)
movq , __Tv1x3twoSi(%rip)
movq , __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 , __Tv1x3oneSi(%rip)
movq , __Tv1x3twoSi(%rip)
movq , __Tv1x5threeSi(%rip)
xorl %eax, %eax
popq %rbp
retq
这会将值 1、2 和 3 粘贴到全局变量中，然后退出。
我的观点是，如果它足够聪明可以做到这一点，请不要尝试用临时变量来事后猜测它。它的工作是弄清楚这一点。事实上，让我们看看它有多聪明。我们将关闭整个模块优化 (-wmo)。没有它，它不会剥离函数，因为它不知道是否有其他东西会调用它们。然后我们可以看看它是怎么写这些函数的。
这是firstFunction()：
__TF1x13firstFunctionFT_T_:
pushq %rbp
movq %rsp, %rbp
movq , __Tv1x3oneSi(%rip)
movq , __Tv1x3twoSi(%rip)
movq , __Tv1x5threeSi(%rip)
popq %rbp
retq
因为它可以看到计算方法只是 return 个常量，所以它内联这些结果并将它们写入全局变量。
现在 secondFunction():
__TF1x14secondFunctionFT_T_:
pushq %rbp
movq %rsp, %rbp
popq %rbp
jmp __TF1x13firstFunctionFT_T_
是的。太聪明了。它意识到 secondFunction() 与 firstFunction() 相同，并且它只是跳转到它。您的函数完全相同，优化器知道这一点。
那么什么是最有效的呢？最容易推理的那个。副作用最少的一种。最容易阅读和调试的一种。这就是您应该关注的效率。让优化器完成它的工作。它真的很聪明。你写的越漂亮、清晰、明显 Swift，优化器就越容易完成它的工作。每次你做一些聪明的事情 "for performance," 你只是让优化器更努力地工作来弄清楚你做了什么（并且可能撤销它）。
只是为了结束这个想法：您创建的局部变量几乎没有提示给编译器。编译器在将您的代码转换为其内部表示 (IR) 时生成其 own 局部变量。 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 行代码，你当然不应该担心你创建的局部变量。它们不仅仅是一个小问题；它们是完全免费的。）