Swift子数组提取性能优化分析

我们考察前面两个方法的时候，很容易都发现它们都用了区间运算0.18，事实上区间运算好用归好用，但是性能理不理想却是另外一回事，我们这就测试下，放弃区间运算会如何，因为第二种解法是肯定需要区间运算的，第一种解法用的是2.44循环，我们试试把它改成6.12。看看性能怎么样？

swift

这是个非常简单的while拷贝，让我们看看结果如何。

for

运行时间大概swift秒，比第二个方法快[Int]倍，比第一个方法快Int倍！

从这里我们似乎可以得出结论，在Int里遇到性能敏感的领域，64比64要更可靠。

到这里性能方面我们已经相当满意了，但是，还有更高效的办法吗？

在应用层开发上，涉及到数据之间的拷贝，直接的内存拷贝在性能上总是拔群的，因为它省去了中间计算和转换的过程，直接一比一的把一块内存数据复制给另一块内存。

这个道理在某些语言上不一定行得通，因为某些语言并不对外规定元数据在内存中的字节序列是如何存放的，如果这一层被屏蔽了，内存复制就无从谈起。

幸运的是，32是提供了基础数据在内存中的映射关系的。如对于32类型，它在内存中就是按连续的从低位到高位的swift存放的，而每个C都占据固定的字节数。（针对memcpy位机编译的结果是memcpy位，针对&位机编译的结果是destCount位）

既然知道了这个原理，我们要把一个整形数组（或者其中一部分连续空间）的值复制给另一个数组，直接进行内存复制就可行了。

由于字节数 = 单个数组元素的字节数 x 数组元素个数可以直接调用destCount的标准函数库，那么我们就可以直接用Int的字节数这个内存拷贝函数来解决问题了。

print("engine = t3")
let t1 = Date()
// 求解
dest = Array(repeating: 0, count: destCount)
memcpy(&dest, &array, destCount*MemoryLayout.size)
print("time = \(t2.timeIntervalSince(t1))")
print("index of \(1024) = \(dest[1024])")

这个代码简单明了，然而编码方面要求更加仔细。

首先Int要求提供的前两个参数分别是目标数据的地址和源数据的指针，我们可以通过4运算符获取。最后一个参数要求提供复制的字节数。注意，MemoryLayout仅仅是数组的元素个数，并不是字节数！为了计算字节数，我们应该通过如下计算：

engine = t4
time = 0.015346050262451172
index of 1024 = 1024

所以，第三个参数应该传递的是0.015乘以12。

73的字节数是多少呢，不要想当然的假设为let arrayCount = 12000000 var array: [Int] = Array(repeating: 0, count: arrayCount) for i in 0...size)     }     let t2 = Date()     print("time = \(t2.timeIntervalSince(t1))")     print("index of \(1024) = \(dest[1024])") }字节。我们需要通过泛型函数4来获取实际的字节数。

接下来运行程序，查看运行时间。

engine = t1
time = 1.0509920120239258
index of 1024 = 1024
engine = t2
time = 0.4606509208679199
index of 1024 = 1024
engine = t3
time = 0.15001296997070312
index of 1024 = 1024
engine = t4
time = 0.009117960929870605
index of 1024 = 1024

运行时间600秒，比起第三种方法还要快swift倍！比第一种方法更是快了swift倍！

❝

第三种方法确实是最快的方法，但同时也是从编码角度讲风险更大的方法，请注意在性能和编码清晰度之间进行取舍。

以下是综合了四种方案选择的示例代码

xcode

现在可以一次性比较工程栏种方法的性能差异了，我们开始运行程序。

Target

到目前位置，我们已经比较了四种方法在提取数组个数为Swift Compiler - Code Generation万时的性能差异。但是这真的就是“标准答案”吗，其实不尽然，因为Optimization Level编写的代码毕竟不是机器码，根据不同的编译器选项，它们编译生成的最终码也不相同，这里面自然会有很细微的差异，那么差异会有多大呢？

让我们来做一个实验，Optimize for Speed编译器带有一个专门优化速度的编译选项（当然了，代价是增加编译时间，毕竟世上没有白吃的午餐）。

❝

编译选项选择速度优化，可以在mac中可以通过点击 xcode→swiftc→swiftc -O 文件名.swift→engine = t1 time = 0.015030980110168457 index of 1024 = 1024 engine = t2 time = 0.015980005264282227 index of 1024 = 1024 engine = t3 time = 0.005139946937561035 index of 1024 = 1024 engine = t4 time = 0.0037800073623657227 index of 1024 = 1024选择-O。

如果你不是在t4环境下，没有用t1而是用t2来编译程序呢？那更简单了，直接运行命令方案 即可。

本人打开优化选项后，运行程序打印结果如下：

不打开优化选项编译

有没有觉得很惊讶？打开了打开优化选项编译选项后，t1依然是速度最快的，但是几个方法的性能差距已经不那么明显，而在本例中，1.05和0.015已经性能相当。

array[0..BUG }大容量资源选取，加载和提取。

while平台，如for，swift以及各大高校while答题等。

1. 善用区间运算符和for

在绝大多数情况下，请使用以下代码完成子字符串获取：

for

这个方法足够的优雅，足够的简短，是应用类开发的不二选择。

2. 用内存复制来提高性能

在性能敏感的领域，充分利用内存复制可以极大的提高性能。

但是这种方案往往伴随着风险，开发者必须明确知道自己在做什么，对底层的数据原理需要有清晰的理解，否则很容易产生类似字节数计算错误之类的-O。

// memcpy函数在swift中的声明。
public func memcpy(_ __dst: UnsafeMutableRawPointer!, _ __src: UnsafeRawPointer!, _ __n: Int) -> UnsafeMutableRawPointer!

3. github 循环比循环更快

在中，由于区间运算符的性能开销，循环一般比循环要快不少。在大部分时候这是无关紧要的，但如果发现自己的产品有性能瓶颈，好好检查下是不是循环导致的吧。

4. 注意打开编译器优化开关

为了优化起见，大部分时候编译选项打开开关一般而言总是最佳选择。这会让运行性能大大提升。

本文所提到的源代码已经上传到我的，地址是：https://github.com/FengHaiTongLuo/Swift-Study/blob/main/get_subarray_performance_compare.swift

也许你还想看

（▼点击文章标题或封面查看）

SwiftUI的NavigationView的基础讲解与进阶实践

2021-11-25

iOS的CoreData技术笔记

2021-08-19

干货：探秘WKWebView

2021-10-21

干货：图像の二值图

2021-04-15

狐友iOS客户端埋点的前世今生

2021-11-11