如何在 Xcode 中减少构建时间/加快编译时间?

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/1479085/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-09-09 03:09:54  来源:igfitidea点击:

How to decrease build times / speed up compile time in Xcode?

iphonexcodebuildcompilationperformance

提问by Brad Parks

What strategies can be used in general to decrease build times for any Xcode project? I'm mostly interested in Xcode specific strategies.

通常可以使用哪些策略来减少任何 Xcode 项目的构建时间?我最感兴趣的是 Xcode 特定的策略。

I'm doing iPhone development using Xcode, and my project is slowly getting bigger and bigger. I find the compile / link phases are starting to take more time than I'd like.

我正在使用Xcode进行iPhone开发,我的项目正在慢慢变得越来越大。我发现编译/链接阶段开始花费比我想要的更多的时间。

Currently, I'm:

目前,我是:

  • Using Static Libraries to make it so most of my code doesn't need to be compiled everytime I clean and build my main project

  • Have removed most resources from my application, and test with a hard coded file system path in the iPhone simulator whenever possible so my resources don't have to constantly be packaged as I make changes to them.

  • 使用静态库来制作它,所以我的大部分代码不需要在每次清理和构建我的主项目时编译

  • 从我的应用程序中删除了大部分资源,并尽可能在 iPhone 模拟器中使用硬编码的文件系统路径进行测试,这样我的资源就不必在我对它们进行更改时不断打包。

I've noticed that the "Checking Dependencies" phase seems to take longer than I'd like. Any tips to decrease that as well would be appreciated!

我注意到“检查依赖关系”阶段似乎比我想要的要长。任何减少这种情况的提示也将不胜感激!

采纳答案by Reed Copsey

Often, the largest thing you can do is to control your inclusion of header files.

通常,您可以做的最重要的事情是控制头文件的包含。

Including "extra" header files in source code dramatically slows down the compilation. This also tends to increase the time required for dependency checking.

在源代码中包含“额外的”头文件会大大减慢编译速度。这也往往会增加依赖性检查所需的时间。

Also, using forward declarationinstead of having headers include other headers can dramatically reduce the number of dependencies, and help all of your timings.

此外,使用前向声明而不是让标头包含其他标头可以显着减少依赖项的数量,并有助于您的所有计时。

回答by fons

I wrote an extensive blog post about how I improved the iOS development cycle at Spotify:

我写了一篇关于我如何改进 Spotify 的 iOS 开发周期的博文:

Shaving off 50% waiting time from the iOS Edit-Build-Test cycle

从 iOS 编辑-构建-测试周期中减少 50% 的等待时间

It boiled down to:

它归结为:

1) Stop generating dSYM bundles.

1) 停止生成 dSYM 包。

2) Avoid compiling with -O4 if using Clang.

2) 如果使用 Clang,请避免使用 -O4 进行编译。

回答by Form

Personally I switched compiler to LLVM-Clang for my Mac development projects and have seen a dramatic decrease in build times. There's also the LLVM-GCC compiler but I'm not sure this would help with build times, still that's something you can try too if LLVM-Clang does not work for iPhone app compilation.

我个人将我的 Mac 开发项目的编译器切换到 LLVM-Clang,并且发现构建时间显着减少。还有 LLVM-GCC 编译器,但我不确定这是否有助于缩短构建时间,如果 LLVM-Clang 不适用于 iPhone 应用程序编译,您仍然可以尝试这样做。

I'm not 100% sure LLVM is supported for development on the iPhone but I think I remember reading in a news feed that it is. That's not an optimization you can implement in your code but it's worth the try!

我不是 100% 肯定 LLVM 支持在 iPhone 上进行开发,但我想我记得在新闻提要中读到它是。这不是您可以在代码中实现的优化,但值得一试!

回答by memmons

The number of threads Xcode will use to perform tasks defaults to the same number of cores your CPU has. For example, a Mac with an Intel Core i7 has two cores, so by default Xcode will use a maximum of two threads. Since compile times are often I/O-bound rather than CPU-bound, increasing the number of threads Xcode uses can provide a significant performance boost for compiles.

Xcode 用于执行任务的线程数默认与 CPU 的内核数相同。例如,配备 Intel Core i7 的 Mac 有两个内核,因此默认情况下 Xcode 将使用最多两个线程。由于编译时间通常受 I/O 限制而不是 CPU 限制,因此增加 Xcode 使用的线程数可以为编译提供显着的性能提升。

Try configuring Xcode to use 3, 4 or 8 threads and see which one provides the best performance for your use case.

尝试将 Xcode 配置为使用 3、4 或 8 个线程,看看哪一个为您的用例提供最佳性能。

You can set the number of processes Xcode uses from Terminal as follows:

您可以从终端设置 Xcode 使用的进程数,如下所示:

defaults write com.apple.Xcode PBXNumberOfParallelBuildSubtasks 4

defaults write com.apple.Xcode PBXNumberOfParallelBuildSubtasks 4

Please see Xcode User Defaultsfor more information.

有关更多信息,请参阅Xcode 用户默认值

回答by Dan Carter

If you're not using 8GB of RAM, upgrade now.

如果您使用的不是 8GB RAM,请立即升级。

I just upgraded my macbook pro from 4GB to 8GB. My project build time went from 2:10 to 0:45. I was floored by the improvement. It also makes web browsing for research snappier and general Xcode performance when indexing, etc.

我刚刚将我的 macbook pro 从 4GB 升级到 8GB。我的项目构建时间从 2:10 到 0:45。我对改进感到震惊。它还可以在索引等时使网络浏览更快速地进行研究和一般的 Xcode 性能。

回答by Tim Keating

Easy answer: add another machine running Xcode on your local network. Xcode incorporates distcc to do distributed compiles. It can even use Bonjour to find other build hosts, which simplifies the process of configuring this greatly. For large builds, distributing can get you a speed increase that is nearly linearly proportional to the number of build machines (2 machines takes half the time, three takes a third and so on).

简单回答:在本地网络上添加另一台运行 Xcode 的机器。Xcode 结合了 distcc 来进行分布式编译。它甚至可以使用 Bonjour 查找其他构建主机,这大大简化了配置过程。对于大型构建,分发可以使您的速度增加几乎与构建机器的数量成线性比例(2 台机器需要一半的时间,三台机器需要三分之一的时间,依此类推)。

To see how to set this up, you can consult this development doc. It also features other useful build time improvement strategies, such as using precompiled headers and predictive builds.

要了解如何设置,您可以查阅此开发文档。它还具有其他有用的构建时间改进策略,例如使用预编译头和预测构建。

Edit: Sadly, it appears Apple has removed this feature as of Xcode 4.3: http://lists.apple.com/archives/xcode-users/2012/Mar/msg00048.html

编辑:遗憾的是,Apple 似乎从 Xcode 4.3 开始删除了此功能:http: //lists.apple.com/archives/xcode-users/2012/Mar/msg00048.html

Xcode 5 has a server version which can do CI, but I doubt this will confer any benefit for ad hoc developer builds. However, there are some unannounced features that should dramatically speed up build times.

Xcode 5 有一个可以进行 CI 的服务器版本,但我怀疑这会给临时开发人员构建带来任何好处。但是,有一些未宣布的功能应该会大大加快构建时间。

回答by bobobobo

One huge tip to halve compile times (for iOS projects at least) is to set Build Settings / Architectures / Build Active Architecture Onlyto YES.

将编译时间减半(至少对于 iOS 项目)的一个重要提示是将Build Settings / Architectures / Build Active Architecture Only 设置YES

What this does (especially with the advent of 64-bit iPads/64-bit compiler) is to not buildthe binary for the architectures you're not currently using.

这样做的作用(尤其是随着 64 位 iPad/64 位编译器的出现)不是为您当前未使用的体系结构构建二进制文件。

Make sure you remember to re-enable this settingon submission to the app store, or your binary will not validate.

确保您记得在提交到应用商店时重新启用此设置,否则您的二进制文件将无法验证。

回答by Wayne

I used a script to make use of a RAM drive, together with some "forward declarations" optimizations my project cleanbuild time went from 53 seconds to 20 seconds.

我使用了一个脚本来利用 RAM 驱动器,以及一些“前向声明”优化,我的项目清理构建时间从 53 秒变为 20 秒。

I was tempted to get the Gui on the AppStore, but opted rather to go for command line. I put the script as part of git repository.

我很想在 AppStore 上获取 Gui,但选择了命令行。我将脚本作为 git 存储库的一部分。

To see the build times, enter this in a terminal: "defaults write com.apple.dt.Xcode ShowBuildOperationDuration YES"

要查看构建时间,请在终端中输入: “defaults write com.apple.dt.Xcode ShowBuildOperationDuration YES”

Restart Xcode to notice the build times in the toolbar. (this is my non clean build time using objective-c) Cached build times

重新启动 Xcode 以注意工具栏中的构建时间。(这是我使用objective-c的非干净构建时间) 缓存构建时间

Adjust the script to your liking. - Note the script clears the derived data folder.

根据您的喜好调整脚本。-注意脚本会清除派生数据文件夹。

#!/bin/sh

#2 GIG RAM
GIGA_BYTES=$((2*1024*1024*1024))

# a sector is 512 bytes
NUMSECTORS=$((${GIGA_BYTES}/512))

#ram disk
mydev=`hdiutil attach -nomount ram://$NUMSECTORS`
newfs_hfs $mydev

# make mount point
MOUNT_POINT=/Users/your_user_name/Library/Developer/Xcode/DerivedData

# ******************************************* 
# ** WARNING - MOUNT POINT WILL BE DELETED ** 
# *******************************************
rm -rf ${MOUNT_POINT}
mkdir -p ${MOUNT_POINT}

# mount
mount -t hfs $mydev ${MOUNT_POINT}
echo unmount $(MOUNT_POINT)

To see the effect and to control the RAM Drive:

要查看效果并控制 RAM 驱动器:

mount                       - see mount points
umount mount_point          - unmount point
diskutil list               - see disks
diskutil eject /dev/diskX   - eject the disk
df -ahl                     - see free space

NOTE:I essentially use the hdiutil provided by macOs. I tried switching the -kernel option (no swapping to disk) on but failed on my machine, saying it is not implemented.

注意:我主要使用 macOs 提供的 hdiutil。我尝试打开 -kernel 选项(不交换到磁盘),但在我的机器上失败了,说它没有实现。

Maybe the new OS coming soon we will see even more improvements as the new file system copy feature is really fast, and possibly makes this script redundant.

也许即将推出的新操作系统我们会看到更多改进,因为新的文件系统复制功能非常快,并且可能会使此脚本变得多余。

回答by Joaquim Paz Carvalho

one word: TmpDisk

一个字:TmpDisk

  1. Use TmpDisk to Create a 1.5Gb RAM disk
  2. Change Xcode > Preferences > Location > Derived Data to /Volumes/1.5Gb/xcode data
  3. Enjoy the speed!
  1. 使用 TmpDisk 创建 1.5Gb RAM 磁盘
  2. 将 Xcode > Preferences > Location > Derived Data 更改为 /Volumes/1.5Gb/xcode data
  3. 享受速度!

回答by Goles

Hey there, I would recommend you to optimize your project's physical structure. There's some good reading about this ( at least in the C++ world ) , but I do objective-C and the same principles often apply.

您好,我建议您优化项目的物理结构。有一些关于这个的很好的读物(至少在 C++ 世界中),但我使用 Objective-C 并且同样的原则经常适用。

Here's a great article about project's physical structure optimization, which tends to improve compile times Games From Within: Physical Structure Part 1

这是一篇关于项目物理结构优化的很棒的文章,它往往会提高编译时间 游戏自内:物理结构第 1 部分

Good luck :)

祝你好运 :)