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

t2	0.46	0.0159
t3	0.15	0.005
t4	0.009	0.00378

t2	0.46	0.0159
t3	0.15	0.005
t4	0.009	0.00378

t2	0.46	0.0159
t3	0.15	0.005
t4	0.009	0.00378

t2	0.46	0.0159
t3	0.15	0.005
t4	0.009	0.00378

t2	0.46	0.0159
t3	0.15	0.005
t4	0.009	0.00378

t2	0.46	0.0159
t3	0.15	0.005
t4	0.009	0.00378

t2	0.46	0.0159
t3	0.15	0.005
t4	0.009	0.00378

本文字数：6912字

预计阅读时间：18分钟

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

在写本文时，本人成功替某一个知名在线答题平台的后台优化一个Swift代码模块的运行效率，并使之上线后运行效率提升了数十倍。经过这次经历，本人决定将优化的经验进行一一分享，优化包括了字符串解析、数组 *** 作、指针 *** 作等。其中一个值得分享的经验就和数组 *** 作有关。

数组对于大部分语言而言，都是相同数据类型的元素的集合。是非常常见的一种数据类型，正因为它非常常见，所以针对它的优化往往能达到立竿见影的效果。

其中，从数组中获取子数组正是诸多应用场景中较为常见的一种。本文通过实际代码分析几种获取子数组的实现方案，比较其中的性能差异，从而让我们在开发中根据自身需要选择合适的方案来解决性能问题。

❝
为了运行测试代码，我们通过Xcode→File→New→Project→command line tool创建一个命令行程序工程，并新建一个任意名字的swift文件进行编辑开发。如果是在非Mac环境下通过swift命令行进行编译，可以编辑一个swift文件后，用swiftc命令行进行编译。如文件main.swift，则编译命令为swiftc main.swift，然后运行./main。

给定问题

我们假设你的项目中需要一个非常大的数组存放数据，数组的元素是基础元数据类型（比如Int）有时候你需要从这大块数组中获取同样不小的子数组，并且获取结果数组。

我们定义源数组变量名为array，赋值数据给它 12000000（一千二百万），这个规模足够用来测试性能了。

let arrayCount = 12000000
var array: [Int] = Array(repeating: 0, count: arrayCount)
for i in 0..


 接下来我们定义一个数组变量 dest 用来接收数据，我们用dest来接收array的子数组，要求它获得 array 的前 6000000 （六百万）个数据元素。
 let destCount = 6000000
var dest: [Int] = []
 接下来我们来按要求写代码来给 dest 进行赋值。
 方法 1：for求解
 这个问题非常简单，但凡有代码基础的人都知道怎么做，直接一个for循环不就完事了吗？我们只要先给dest赋值成指定大小的数组，然后用for循环挨个赋值即可。
 print("engine = t1")
let t1 = Date()
// 求解
dest = Array(repeating: 0, count: destCount)
for i in 0..

 这段代码简单明了，非常好懂。
 另一方面，为了测试代码的性能，我们通过Date类型的t1和t2用来计算求解过程的运行时间，最后在运行完毕后，再通过获取dest下标1024的值来验证结果是否正确（当然这并非严谨验证，仅仅是一个示例）。
 在本人机器上测试，打印结果如下：
 engine = t1
time = 1.131295919418335
index of 1024 = 1024
 打印出来的结果显示，在本机环境下，处理时间需要一秒钟。
 一秒钟算快还是算慢？这要比较了才知道了。
 
  ❝
  测试的读秒在不同配置的机器上结果是有差异的。所以算法时间比较不应以不同机器间的差异为准，而应以同一台机器不同算法之间的时间比例差距为准。
 
 方法2：数组内置的区间运算符求解
 事实上，swfit数组提供了一个非常方便的内置函数，该函数声明如下：
 subscript(Range) -> ArraySlice
 该函数的功能正是提供一个数组的子数组，完美符合我们的要求！
 该函数是一个区间运算符函数，它的效果和函数调用是一样的，只是调用方法上是通过例如 [a.. 的方法来完成。

 另外，该函数返回的不是数组类型，而是一个被称为 ArraySlice 的类型，该类型描述了原数组中的一个区间数据，这样就避免了计算时直接拷贝出一个数组的性能消耗，因为调用者可能并不需要获取拷贝，只想拿到区间。
 而我们的当前解题需求是需要拿到数组拷贝，所以要补充额外的代码，具体如下。
 print("engine = t2")
let t1 = Date()
// 求解
dest = array[0..array[0.. }
let t2 = Date()
print("time = \(t2.timeIntervalSince(t1))")
print("index of \(1024) = \(dest[1024])")
 在第二个解法中，我们用ArraySlice获取子数组区间类型map，再利用Int方法生成新的数组，数组的元素值正是数组元素的值engine = t2
time = 0.45145297050476074
index of 1024 = 1024，所以直接用内置变量2即可完成 *** 作。
 接下来运行代码，观察打印结果。
 1
 方法2.5足足比方法2快了dest倍！我们的性能往前迈进了一大步。而且，方法map { swift }还有一个很大的优点，我们不需要单独写一行代码来创建swift数组，一行代码我们就解决了一切！
 
  ❝
  关于map这段代码，是{ swift }特有的语法糖，可以通过return的语言指导文档了解它的特性。事实上它就是一个普通的名字为{ while }的函数，该函数接收一个回调函数作为参数，这个参数我们通过begin..提供了，该回调函数会提供原数组（或者迭代器）的每一个元素作为参数，然后要求你返回一个值，你返回的值会作为map返回的数组的元素值。而for正是代表着迭代的每个元素，因为我们要返回的正是该元素的类型，所以直接返回即可。又因为while的语法机制规定当我们单独提供一个语句时，该语句可以作为返回值，所以又省去了print("engine = t3")
let t1 = Date()
dest = Array(repeating: 0, count: destCount)
// 求解
var i = 0
while i < destCount {
    dest[i] = array[i]
    i += 1
}
print("time = \(t2.timeIntervalSince(t1))")
print("index of \(1024) = \(dest[1024])")语法。最后就是你看到的while 。如果你看到这里还是不太清楚，也不要紧，并不妨碍本文的主题。请保持好奇心继续前进。

 

 方法3：engine = t3
time = 0.18484008312225342
index of 1024 = 1024循环
 我们考察前面两个方法的时候，很容易都发现它们都用了区间运算0.18，事实上区间运算好用归好用，但是性能理不理想却是另外一回事，我们这就测试下，放弃区间运算会如何，因为第二种解法是肯定需要区间运算的，第一种解法用的是2.44循环，我们试试把它改成6.12。看看性能怎么样？
 swift
 这是个非常简单的while拷贝，让我们看看结果如何。
 for
 运行时间大概swift秒，比第二个方法快[Int]倍，比第一个方法快Int倍！
 从这里我们似乎可以得出结论，在Int里遇到性能敏感的领域，64比64要更可靠。
 到这里性能方面我们已经相当满意了，但是，还有更高效的办法吗？
 方法4：内存复制
 在应用层开发上，涉及到数据之间的拷贝，直接的内存拷贝在性能上总是拔群的，因为它省去了中间计算和转换的过程，直接一比一的把一块内存数据复制给另一块内存。
 这个道理在某些语言上不一定行得通，因为某些语言并不对外规定元数据在内存中的字节序列是如何存放的，如果这一层被屏蔽了，内存复制就无从谈起。
 幸运的是，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已经性能相当。
 swiftwhilememcpyarray[begin..memcpy音视频t2 0.46 0.0159
t3 0.15 0.005
t4 0.009 0.00378

 
  ❝
  可以看出，图片编译器的速度优化表现非常杰出，优化后的游戏循环性能表现已经直逼Online Judge的速度。所以在如果项目是对性能要求很高的话，一定要打开编译速度优化。但是即便如此，研究高性能的代码方案依旧不能忽视，首先性能优异的代码方案很多不依赖于编译器优化会始终保持出色的性能，其次在不同的需求环境下，我们可能会选择不同的编译选项，而非始终选择“速度优先”，这时候好的高性能代码设计可以在即使是非速度优先的编译选项下依然有良好的表现。
 
 取舍分析
 大部分时候，我们开发产品时都不会用到这么大的数据量。
 所以，在应用编程的场景下，很多时候第二种方案，即 LeetCode 都是优雅又推荐的方案。因为它只需要一行代码，且简单易读。而且在开启了编译优化后，它的表现已经足够让人满意。
 但是确实存在一些开发场景，性能高度优化的方案 - 如牛客网，是有价值的，甚至是至关重要的。
 包括但不限于：
 ACM、map中，大块字节序列的处理和获取。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					
										


					
						欢迎分享，转载请注明来源：内存溢出
原文地址: http://outofmemory.cn/web/993709.html

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

发表评论

评论列表（0条）