You can increase the build efficiency by using pre-built dynamic frameworks and libraries. Pre-build dependenciesĮvery project has various dependencies that might slow down the build process. I’ve described the ways of doing it in one of my previous posts. It has an impact on a project’s build time by slowing it down, thus needs to be found and removed. use correct access modifiers for your classes, structs, enums, extensions, etc.Īs your project evolves there could appear unreachable code that is not used anymore or will never be reached.You can do the next to reduce the work that compiler should do on rebuild: On the other hand, adding or removing a new function or an entity in the file will trigger a re-compilation of all the files that depend on it. If you make a change within a function body, the compiler is smart enough to know that only that file will need to be recompiled.
You might probably know that Swift’s dependency model is based around files. It is quite important to understand how Swift compiler works and finds the files to recompile.
Just like that we can fix the rest of the issues and reduce the total build time from 92sec to 57sec. As an improvement, we can specify the type explicitly and split it up into two: No surprises, that it took a while to type check one. There is a complex expression with the chain of infix operator |> invocations. The function configureBaseGradientView() was mentioned 20 times in the Xcode build log and each time it took 10067ms to perform type checking. Let’s have a look at the biggest offender. Here are the results for the Kickstarter project I’ve got with Build Time Analyzer: To help us find areas where the Swift compiler struggled, Xcode can generate a warning for any function or expression that took longer than specified limit to type-check. Source code improvements Find code that compiles slowlyĪs we’ve learned in the previous article, one of the main slowdowns in the compilation process is the evaluation of complex expressions. You should always create one for Release builds, but you won’t use it for Debug build most of the times. For Release builds it can be set to Optimize for Speed.ĭebug Information Format (DEBUG_INFORMATION_FORMAT)ĭSYM is a Debug Symbol file, that contains debug information to symbolicate and interpret crash reports. Debug builds should be configured with No Optimization, since we need a fast compile time. Code optimizations result in slower build times because of the extra work involved in the optimization process. The Optimization Level setting defines a way we’d like to optimize the build. Optimization Level (SWIFT_OPTIMIZATION_LEVEL) Use Whole Module for Release to rebuild all Swift source files in the module and apply certain code optimizations.
Set it to Incremental for Debug configuration and only rebuild the Swift source files that are out of date. This setting defines how the Swift files are rebuilt within a module. Make sure that Debug is set to Yes and Release is set to No.Ĭompilation Mode (SWIFT_COMPILATION_MODE) The release build should contain all supported architectures because one is shipped via App Store to all variety of users devices.
#Compiling code in xcode 10 simulator
In the development stage, we build the project either on device or simulator (active architecture). If enabled, Xcode creates a binary for the active architecture only. Build Active Architecture Only (ONLY_ACTIVE_ARCH) But it is worth checking ones for an existing project, just in case someone changed them accidentally. These settings are pre-filled by default when you create a new project. The first thing we should do is to check that our project is configured optimally for Debug configuration. Let’s dive into details! Build settings optimizations I’d split the build time optimization techniques in the following way: Using build time metrics above we can now find the most time-consuming tasks within the build process and define what can be improved. Here is the Xcode build timing summary we received for the Kickstarter iOS project: What to optimiseīefore we begin, I’d suggest getting initial build time metrics for your project. In this blog post, I’ll show you how we can resolve the Xcode build time bottlenecks and speed it up.
#Compiling code in xcode 10 how to
In the previous article we’ve learned how to measure the Xcode build time and get some metrics to analyze. It is quite important to keep you build time under control and improve one if needed. The build time speedup is crucial for developers productivity and the product’s time to market.
0 kommentar(er)
