Swift is basically fast, and iOS devices are also very fast, so the following tips may not be necessary. But it is not unnecessary, because maybe we will have to deal with slow devices or large numbers, …
Set Optimization Level in Build Settings
The first thing you need to optimize is for Xcode to optimize itself. Go to the build settings section, and look to the “Swift Compiler – Code Generation” section, the “Optimization Level” section will have 3 options for you:
- No Optimization
- Optimization for Speed
- Optimization for Size
The name is very clear, you can set “Optimization for Speed” for the release to increase user experience or to “Optimization for Size” for debug mode so that the build can be faster, cost less. more development time. Of course this setting depends on what your project needs.
Use “Final” and “Private” for Methods and Classes
Swift has a lot of support for Protocol Oriented instead of Object-Oriented, which means our code should not use too much unnecessary inheritance. When calling a function that is not final yet, keep in mind that it will always look for any subclasses, or if it will be overridden by a subclass, repeat until it reaches the end. So if your method is final, or that class can no longer inherit, putting “final” will help reduce the work of the compiler.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 | class MethodAccess: NSObject { final func finalFunction(x : Int)->Int { return x + 1 } func notFinalFunction(x : Int)->Int { return x + 1 } } class PerformanceTuningTests: XCTestCase { func testFinalFunction() { // this test runs 30% faster than "testNotFinalFunction" let methodAccess = MethodAccess() self.measure { for _ in 0...100000000 { _ = methodAccess.finalFunction(x: 100) } } } func testNotFinalFunction() { let methodAccess = MethodAccess() self.measure { for _ in 0...100000000 { _ = methodAccess.notFinalFunction(x: 100) } } } } |
When you choose to optimize your swift code in the build settings, the “final” properties will ensure to be called directly without looking for subclass implementions.
Avoid “Print” in Release Builds
Printing consoles helps a lot for debugging, but leaving them in the release is a bad habit. Leaving such lines of code print will be costly. Because it is an I / O task, it is time-consuming and greatly slower. The following example tests between using print and not using.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 | class PerformanceTuningTests: XCTestCase { func testWithPrint() { // this test runs 1600 times slower! let methodAccess = MethodAccess() self.measure { for _ in 0...100000 { _ = methodAccess.returnValue(x: 100, withPrint: true) } } } func testWithOutPrint() { let methodAccess = MethodAccess() self.measure { for _ in 0...100000 { _ = methodAccess.returnValue(x: 100, withPrint: false) } } } } |
The way to optimize the code here is to use a final class that helps make this print instead of using the print function directly. In the print function of this custom class, please distinguish between the Debug and Release environments, so that you do not have to be afraid that you forgot to delete the print somewhere when releasing.
1 2 3 4 5 6 | func printToConsole(message : String) { #if DEBUG print(message) #endif } |
“Inline” Your Code
The separation of functions into small functions, each function performs a specific task as well. But this also reduces performance, calling the funtions in the function will cost more than performing the compile from start to finish. However, running out of code in a function is not good, either makes the code reuse bad, or violates the SOLID principle – a function that does too much. So consider this, do not trade a little performance that breaks the rules, conventions, …
Use Values (Structs) and Not References (Classes) in Array
You probably already know that NSArray only stores objects, while Array stores both references (values) and value types. When an array of values contains references, it automatically gets the properties of NSArray, which makes it difficult to optimize. But if the array only contains values of value type like Int or Struct then Struct is a lot easier for the compiler. Storing Struct in an array is much more advantageous and efficient than Class .
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 | class PerformanceTuningTests: XCTestCase { func testInsertingValuesIntoArray() { // this test runs 4 times faster than "testInsertingObjectsIntoArray" let methodAccess = MethodAccess() self.measure { methodAccess.valuesInArray() } } func testInsertingObjectsIntoArray() { let methodAccess = MethodAccess() self.measure { methodAccess.objectsInArray() } } } struct PhonebookEntry { var name : String var number : [Int] } class PhonebookEntryClass { var name : String var number : [Int] init(name : String, number : [Int]) { self.name = name self.number = number } } class MethodAccess: NSObject { func valuesInArray() { var a = [PhonebookEntry]() for _ in 1...1000000 { let entry = PhonebookEntry(name: "a", number: [1]) a.append(entry) } } func objectsInArray() { var a = [PhonebookEntryClass]() for _ in 1...1000000 { let entry = PhonebookEntryClass(name: "a", number: [1]) a.append(entry) } } } |
In the above example, filling the array by struct produces a result 4 times faster.
Limit Protocols to Class Only if Possible.
If you know that this protocol is for class only, define it with the class . This helps the compiler know that this protocol is only for class and helps ARC (Automatic Reference Counting) run your code faster.
1 2 3 4 | protocol Person : class { } |
Above are some small tips to help your Swift code run faster and more efficiently. The article is referenced from the source: 9 Ways to boost your Swift code performance