In the Compiler for Swift 4.1, a new optimization option is provided. You can reduce code generation size.

Optimization of the generated code is a function provided by many compilers, and compilers prior to Swift also provide Optimization. If you open the Build Settings of the XCode project, you can find an option called Optimization Level. By default, XCode will enable compiler optimization for projects under Release by default:

This option passes a -o parameter to the compiler at actual compile time, which represents performance optimization.

New compilation options

In addition to the above performance optimizations, XCode 9.3 also provides another new option, Osize, to optimize code size:

-o and -osize are mutually exclusive. Only one parameter can be selected. -o Optimizes the execution speed of the code, but if the execution speed increases, some space will be sacrificed.

Conversely -Osize is an optimization option specifically designed to save code space. So how much do they gain and lose? This is also explained on the swift.org Blog:

-Osize Can reduce code space usage by 5%-30% depending on the project. This results in a loss of approximately 5% of runtime performance compared to -0. If your project is not particularly speed sensitive and can accept a slight performance penalty, then -osize is worth using.

Single File and Whole Module

In addition to -o and -osize, there is another concept worth mentioning. Single File and Whole Module. In previous versions of XCode, these two options were set together with -o. In XCode 9.3, they are separated and can be set independently:

The Single File and Whole Module modes correspond to how the compiler handles optimizations.

Single File is optimized File by File, which has the advantage of reducing compilation time for incremental compiled projects and eliminating the need to recompile every time for unchanged source files. And can make full use of multi-core CPU, optimize multiple files in parallel, improve compilation speed.

The disadvantage is that it can’t handle optimization operations that require cross-file optimization. If a file is referenced multiple times, the optimization of the referenced file will repeatedly reprocess the referenced file, which can affect performance if there are many such cross-references in your project.

Whole Module treats all files of the project as a Whole, avoiding the problem of repeatedly processing the same File in Single File mode, and maximizing optimization, including cross-file optimization operations.

The disadvantages are that you can’t take full advantage of the performance of multi-core processors, and for incremental compilation, you also need to recompile the entire project each time.

XCode’s default Settings use Whole Module mode. I specially searched and found a good summary on Stack Overflow, and posted it for your reference:

The address of this post is https://stackoverflow.com/questions/47998583/whats-the-difference-between-single-file-optimization-vs-whole-module-optim Izat.

My understanding of this option is to use the default Whole Module optimization if there are no special cases. It sacrifices some compilation performance, but the optimization results are the best.

What is compiler optimization

Compilation optimization is a big topic. In short, the code we write in high-level languages is based to a greater extent on the logic of our minds. And then, through the compiler, it becomes the logic of the machine. For example, if we develop a project now, we pay more attention to the implementation of business logic, such as clicking the buy button, can call the order function normally. Or when the user completes a certain function, can pop up the evaluation prompt according to the predetermined requirements.

We’re less likely to spend time on questions like how to write a line of code to reduce power consumption, or how to improve multi-core CPU utilization. Compilation optimization is a feature that helps us deal with these problems to some extent.

Here’s an example from a swift.org Blog:

This code, for example, defines an attribute x that returns the integer 27 via a function. If you turn on compiler optimization, it is possible for the compiler to optimize this property to an inline function (because the function body is relatively simple). An inline function expands directly into code where it is called. Like this:

The code above is actually compiled and optimized to look like this:

Because the overhead of calling a function is much higher when the program is actually executing than when the code is actually executing, it is more efficient to optimize smaller functions to be inline.

This is an example of compiler optimization. The inline substitution is used to optimize performance. As you can imagine, if you call ins.x several times in your code, they will all be replaced. The total amount of your code will inevitably be increased by compilation optimizations. Too much inline, while helpful for performance, can definitely increase the size of your code.

This is also a law of conservation in programming, under the same conditions, space and performance can not have both, there is a trade-off.

The difference between -o and -osize should be better understood by this explanation. As explained by the official Blog, -o is more focused on optimizing performance, while also increasing code space. -osize focuses on code size, as is clearly stated on the official Blog. -osize is a more cautious optimization standard for inline functions than -o. From this point of view, with less inline optimization, the code size will naturally decrease and the same performance will be slightly reduced.

Of course, this is just an example of inline optimization to help you understand how compilation optimizations work. The actual compilation optimization operation is far more complex than what we describe here.

More introduction about – Osize, everybody can have a look at swift.org this article Blog:https://swift.org/blog/osize

conclusion

The -osize compilation option added to XCode 9.3 gives you a new option. This article also shares some basic concepts about compiler optimization by introducing it, which may help you to talk about it when discussing the problem. Also, there are a lot of projects that need to optimize the size of the space. I think this is one of the reasons why the -osize compilation option is available. If your project needs it, try it out.

Best, please take a few seconds to do a small survey, when is the most convenient for you to read the article, according to this adjustment of the article push time.