Tik Tok Swift compilation optimization - 60% faster compilation based on custom Toolchain

The optimization solution is based on the Swift Toolchain source code. This article will no longer discuss the basic concepts and configuration processes related to Toolchain, but only focus on the solution itself .

background

As the number of mixed-compilation business scenarios increases, performance pain points in development begin to emerge. The problem is obviously concentrated on the modification of the header files of the OC warehouse that the Swift environment depends on. Therefore, the infrastructure architecture focuses on the performance analysis of the interface layer dependency, striving to solve the performance bottleneck.

The Tik Tok basic technology team used the custom Toolchain capabilities to customize compilation parameters and trim the Clang Header specified content, ultimately increasing compilation speed by 60%.

This plan was launched at the end of November 2022 and has been running stably on Douyin for nearly 5 months. Let us review the entire process from proposal to implementation.

Preliminary analysis

In a mixed compilation scenario, to ensure that OC and Swift interoperate as fully as possible, modularization cannot be enabled only in the Swift compilation context. The Clang Header exported by Swift compilation appears in the project as ​$(project_name)-Swift.h​ ​​, and the OC dependencies that need to be re-exported are exported as modules. This means that if OC compilation does not enable modularization, the header files provided by Swift cannot be used correctly.

As shown in the figure, you can't have both. In order to parse the statement ​@import A;​ ​​, Objc Pod D introduces ​A.modulemap​​ ​. Therefore, its interoperability with A can no longer be based on the logic of text import, but must be fully modularized.

For TikTok, the historical burden of a large number of header files in the giant OC project made the introduction of modularization in OC compilation a disaster. In a modular environment, the time it takes for the cache system to decide whether to hit the .o cache is longer than the time it takes to recompile in a text environment; incremental compilation will also lead to extensive module recompilation, and changing a header file will require waiting for several minutes.

Transitive dependency management is a long-term project, but compilation optimization cannot wait that long. We need a solution that can be solved quickly.

Optimization effect

Before introducing the solution, let me first give the conclusion.

In the Douyin project, select the OC&Swift mixed repository with the largest amount of code for testing:

• OC incremental compilation: Select the OC interface layer header files that Swift depends on for modification, and the compilation time is reduced by 60%
• Swift incremental compilation: Select the Swift public class that OC depends on for modification, the compilation time is similar, no change
• Full compilation: Clear the local compilation cache to perform a clean build, reducing compilation time by 17%

It can be seen that this solution has greatly improved the compilation speed. Next, let's review the process of the entire solution from pre-research to launch.

Solution Principle

The key to solving the problem is to reduce the time spent on precompiling OC header files. There are two ideas:

• Long-term: The time-consuming root cause of module parsing lies in transitive dependencies. Due to the characteristics of modules, the transitive dependencies of header files contained in different modules will greatly expand the scope of the impact of module incremental recompilation. Under the existing engineering architecture system, the business library has strictly controlled the transitive dependencies of the interface layer, so the long-term solution will gradually promote the governance of transitive dependency issues in the basic library.
• Short term: Convert OC header file precompilation back to text import, that is, cut -fmodule-map-files injection, but still retain support for OC calling Swift code

Swift will declare the C/OC modules used by its own interface layer (i.e. public/open) in the form of ​@import aaa​ in ​xxx-Swift.h​ . This requires that these modules must also be visible to the OC side when the OC side uses this header file. If we want to achieve our goal, we need to tailor these declarations. This requires the support of a custom tool chain.

The effectiveness test of this optimization plan is aimed at short-term plans.

By modifying the compiler, the Clang Header Interface generated by Swift compilation is trimmed, and @import outside the system library is deleted. The OC side manually completes the dependency where the header file is referenced. That is, at the expense of temporarily sacrificing the self-contained interface, the OC side no longer needs to care about module-related factors. To support finer-grained control, by injecting compilation parameters into the compiler, the activation of this function can be controlled for different components, and more specific trimming content can be achieved.

It is relatively easy to remove ​-fmodule-map-files​ . You only need to modify ​OTHER_CFLAGS​ to turn off the injection of ​-fmodule-map-files​ .

Preliminary research

Solution Disassembly

Let's first break down the entire solution into tasks, so that we can analyze the dependencies between the various parts and save time in the preliminary research stage.

A tool chain-related implementation solution must ensure its stability, so it must be able to be externally controlled and switched in a simple way.

From the perspective of release, toolchain release is not like business code, which can be released flexibly like the configuration stored in the development warehouse. Therefore, the toolchain code should be kept as stable as possible and not modified unless necessary.

Based on these two principles, we can break it down into:

1. Analyze the parameter parsing mechanism of ​swiftc​ ​​, and splice new custom parameters in the parameter list at compile time to control the clipping ability. ​swiftc​​​ is an entry point for the actual front-end ​swift-frontend​ ​​. As mentioned in detail below, the parameter list injected into swiftc does not always appear in the same complete set in each ​swift-frontend​​​ subtask, and the mechanism of action needs further analysis.

2. Based on the consideration of fine-grained control, the parameter selection passes in a configuration file, which contains a whitelist to determine which ​@import Module​ can be retained. We have also considered blacklists, but the dependencies of actual projects are complicated. Both Cocoapods and seer can only describe the dependencies at the project level, but cannot guarantee the dependencies during actual compilation, making it difficult to build a comprehensive business blacklist. The system library whitelist is relatively fixed and does not require frequent maintenance.

3. Find the specific function that generates-Swift.h and the logic that writes ​@import Module;​ for tailoring.

4. Load the whitelist file at the write logic and filter it.

5. Complete the verification of the Toolchain without perception through local verification, and launch the test Toolchain.

6. Grayscale verification.

7. The unified version is released online.

Quick Verification

In order to verify whether the direction is correct and give confidence to business colleagues who are troubled by time-consuming compilation, it is necessary to first find the most critical points for quick verification.

Therefore, we decided to turn off all ​@import Module;​ generation logic of -Swift.h. At this time, our understanding of the entire Swift source code was still vague, but we only needed to look for similar logic like ​<< "@import"​ or other file writing logic and then filter it. Fortunately, this process did not take too long.

We quickly found this logic and commented ​out << "@import " << Name.str() << ";\n";​ directly. The package verification was successful and the data report at the beginning of this article was issued, which gave the business colleagues a reassurance.

Next, we can proceed to perform other tasks step by step in a steady and orderly manner.

Development and debugging

Swift-frontend parameter parsing process

So we turned our attention to other native parameters used at the front-end level and referred to their writing methods. Soon we locked our eyes on ​module-cache-path​ , which is a required parameter for Swift front-end compilation. It specifies the module cache location and passes in a path afterwards, which fully meets our requirements.

Based on the analysis of this parameter, we can get the parameter parsing process of the -frontend stage. The specific investigation process will not be expanded, and we will simply go through the process.

The simple process is shown above. The following is a detailed code location for modifying the parameter parsing process.

definition

Here we use a language very similar to Python, TableGen (https://llvm.org/docs/TableGen/) launched by LLVM. The following flags are what we need

• FrontendOption front-end parameter. Only with this flag will the front-end parameter parsing process be entered, and the Clang Header generation process occurs in the front-end process.
• ArgumentIsPath The parameter is a path, telling the compiler that the parameter is followed by a path string as a parameter

Custom parameters that follow this form:

The second EQ definition is actually an Alias, which defines that parameters can be passed in the form of "flag=arg", and has no other additional effects.

Use the ​tablegen​ tool to generate the contents of Options.td into Options.inc, as shown below

Combined with the OPTION definition in Options.h in the Swift source code, import and provide it to the cpp code for use

Analysis

The parsing process occurs in the parameter parsing process of CompilerInvOCation

In the ArgsToFrontendOptionsConverter method, read the required information from the parameter list and assign it to Opts

Opts is an instance of the FrontOptions type. We need to define a string here to store the parameters we need.

Opts will circulate throughout the entire front-end process, providing necessary parameters for each link.

Clang Header Generation Process

The flowchart of the calling process is as follows. PrintAsClang is a relatively independent module. We only need to focus on the two red links when making changes.

Add input parameter definition

Add two parameters to the original method definition, which are the whitelist file path we passed in and the diagnostic information. The diagnostic information will be mentioned later and is used to prompt some custom errors.

It is the same here, adding two parameter definitions.

Whitelist analysis

printAsClangHeader This is one of our main modifications. In this function_ref, we parse the content of the file pointed to by the allow list path, obtain the module name specified by the whitelist, and pass it to the next link as a parameter.

The writeImports method adds a function_ref to the original method, which can be understood as a ​lambda​ expression, which is the whitelist parsing process we just did.

Perform whitelist screening at the specific writing of ​@import Module;​ ​​, and allow writing within the whitelist, otherwise skip it.

Customizing diagnostic information

Add two custom entries to DiagnosticsClangImporter.def. Error is used to prompt parsing errors, and note only prompts that the whitelist is empty. Being empty is an allowed operation, and it degenerates to the default logic.

Earlier, we passed in the Diags instance in the method definition. If we want to prompt information, we can simply call it. Note will only output to the log, and error will interrupt the compilation process.

Verification and launch

You can use the cloud build machine to type out the test Toolchain, download it locally, integrate it into Xcode, and verify it on TikTok.

Add custom parameters to the compilation parameters of the specified mixed component to successfully build it.

postscript

Swift toolchain customization is a direction with infinite possibilities, including efficiency improvements such as compilation optimization, etc., which can perform deep optimizations at the bottom layer that are difficult to perform at the traditional architecture layer. There is still a lot to be done in this area in the future, and I believe there will be more experience to share with everyone.