如何减少Xcode的构建时间/加快编译时间？

69

通常可以使用什么策略来减少任何Xcode项目的构建时间？我对Xcode特定策略最感兴趣。

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

目前，我是：

  • 使用静态库来做到这一点，这样我每次清理和构建主项目时就不需要编译大多数代码

  • 已经从我的应用程序中删除了大多数资源，并在可能的情况下在iPhone模拟器中使用硬编码的文件系统路径进行了测试，因此在我对其进行更改时，不必经常打包我的资源。

我注意到，“检查依赖项”阶段似乎花费的时间比我想要的要长。任何技巧，以减少这一点，将不胜感激！

iphone  xcode  build  compilation  performance 
— 布莱德公园
source

Answers:

56

通常，您可以做的最大的事情就是控制头文件的包含。

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

此外，使用前向声明而不是让头包含其他头可以极大地减少依赖项的数量，并帮助您进行所有时序安排。

— 里德·科普西
source
23

我写了一篇有关如何改善Spotify的iOS开发周期的博客文章：

从iOS Edit-Build-Test周期减少了50％的等待时间

归结为：

1）停止生成dSYM捆绑包。

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

— s
source
感谢您的帮助，您的博客文章易于执行。
— elliotrock
@elliotrock我很高兴这仍然有用（我本来会假设XCode现在使用更好的默认值）。
— 2016年
甚至几年后，您的DWARF提示也令人难以置信，@fons dude。它看起来像你从Spotify的移动上，它仍然mindboggling嘿嘿:)
— Fattie
@fons静态库呢？对于他们而言，在发行版本中使用dSYM没有意义。在我的情况下，大多数代码都在静态库中，只有在构建最终二进制文件（从我的项目链接到所有这些静态库中）时才具有dSYM才有意义。
— 帕维尔P
谷歌搜索给出了这样的答案：“除了不需要dSYM文件并且不会为静态库或目标文件产品创建它” –是的，对于静态库使用dSYM根本没有意义。
— 帕维尔P
17

我个人将Mac开发项目的编译器切换到LLVM-Clang，并且看到构建时间大大减少。还有LLVM-GCC编译器，但是我不确定这对构建时间是否有帮助，但是如果LLVM-Clang无法用于iPhone应用程序编译，那还是可以尝试的方法。

我不是100％肯定支持LLVM在iPhone上进行开发，但是我想我记得在新闻提要中看到过。这不是您可以在代码中实现的优化，但值得尝试！

— 形成
source
感谢您的建议。我只是进行了几次搜索，听起来应该可行，并且它已集成到XCode（至少3.2）中。我将检查项目当前是否正在使用它，因为我猜较旧的XCode项目文件可能仍默认使用旧的“纯gcc”方法。谢谢！
— 布莱德·帕克斯
我从未让LLVM能够为iPhone编译。真的受支持吗？
— MrMage
它不支持iPhone，但对于模拟器建立它工作得很好，你只需要条件化基于SDK的设置
— 路易斯Gerbarg
1
这是指向XCode 3.2支持的不同编译器类型的更多信息的链接：maccompanion.com/macc/archives/September2009/Columns/… 我还没有Snow Leopard（XCode 3.2所需吗？），但我想我会必须考虑得到它。上面的网址中的一句话是：“如果可以使用Clang，则在编译时，性能将提高近三倍，这是对gcc的重大改进。（我能听到老CodeWarrior用户现在在叹息“最后！”。）。但我不知道这是否与iPhone或不工作
— 布拉德·公园
12

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

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

您可以按照以下步骤在Terminal中设置Xcode使用的进程数：

defaults write com.apple.Xcode PBXNumberOfParallelBuildSubtasks 4

有关更多信息，请参见Xcode用户默认值。

— 记忆
source
3
此选项已不存在。
— 鸭子
12

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

我刚刚将Macbook Pro从4GB升级到8GB。我的项目构建时间从2:10到0:45。我为改进感到震惊。它还可以使Web浏览在索引等方面更快速，更通用的Xcode性能。

— 丹·卡特
source
您是否知道该策略是否适用于最新的XCode版本（例如4.5），因为我似乎注意到XCode内存使用量显着减少了？
3
我有16GB，但仍然很慢
— Hai Feng Kao
我有32GB，但仍然很慢
— Naresh
11

简单的答案：在本地网络上添加另一台运行Xcode的计算机。Xcode结合了distcc来进行分布式编译。它甚至可以使用Bonjour查找其他构建主机，从而大大简化了配置过程。对于大型构建，分发可以使您的速度提高几乎与构建机器的数量成线性比例（2台机器花费一半的时间，三台机器花费三分之一的时间，依此类推）。

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

编辑：可悲的是，苹果似乎已从Xcode 4.3删除了此功能：http : //lists.apple.com/archives/xcode-users/2012/Mar/msg00048.html

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

— 蒂姆·基廷
source
1
我认为这不会改善构建的检查依赖关系部分，而只是进行编译。
— wbyoung，2009年
2
的确如此，但是这个问题似乎对缩短编译时间的广泛策略开放，因此我认为它仍然有意义。
— Tim Keating 2010年
我的经验是，添加其他构建服务器实际上会增加构建时间。特别是，Xcode默认不构建在主计算机上，仅将其用于协调。因此，如果您坐在的机器的速度与第二台机器的速度相同或更快，则速度实际上会降低。即使在“正常”网络（没有针对构建服务器场进行优化的网络）上分布了几台其他计算机，我也发现了好坏参半的结果。
— 罗布·纳皮尔
有趣的见解...“没有默认的主人”似乎是愚蠢的选择。我还没有使用具有任何大小的代码库的Xcode分布式构建，但是我曾经将distcc与一个相当大的linux项目一起使用，甚至还添加了一个糟糕的机器。当然，它对链接时间没有任何作用，因此，如果您有一个包含大量链接器工作的项目（例如，具有许多模板的C ++项目），那将无法真正帮助您。
— Tim Keating
7

将编译时间减半的一个重要技巧（至少对于iOS项目而言）是将Build Settings / Architectures / Build Active Architecture Only Only设置为YES。

这是做什么的（尤其是在64位iPad / 64位编译器出现时）是不为您当前不使用的体系结构构建二进制文件。

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

— 波波波波
source
2
这是一个很好的建议，并且现在是Xcode中新项目的默认设置。确保仅对您的Debug构建配置启用此功能，这样您就不必记住在存档（使用Release构建配置）时重新启用该设置。
— smileyborg
怎么做？
— 丹尼尔·斯普林格
5

我使用脚本来利用RAM驱动器，并进行了一些“前向声明”优化，我的项目的干净构建时间从53秒缩短到20秒。

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

要查看构建时间，请在终端中输入： “默认写com.apple.dt.Xcode ShowBuildOperationDuration是”

重新启动Xcode以注意工具栏中的构建时间。（这是我使用objective-c进行的不干净的构建时间） 缓存的构建时间

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

#!/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)

要查看效果并控制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

注意： 我基本上使用macOs提供的hdiutil。我尝试打开-kernel选项（不交换到磁盘），但是在我的机器上失败，并说未实现。

也许新操作系统即将面世，我们将看到更多改进，因为新文件系统复制功能确实非常快，并且可能使此脚本变得多余。

— 韦恩
source
2

您提到了对最常用的文件使用静态库以防止编译。您可以通过将经常使用的标头放在代码中，而不是在预编译标头中的静态库中，来完成类似的操作。至少它们只会被编译一次。

如果您的项目中有多种编译类型（例如，Obj-C，Obj-C ++，C ++），则必须小心避免出现问题。

— 四联
source
2

嘿，我建议您优化项目的物理结构。关于这一点（至少在C ++世界中）有一些不错的读物，但是我做的是Objective-C，并且经常应用相同的原理。

下面是关于项目的物理结构的优化，这往往会提高编译时间一大篇 游戏从内：物理结构第1部分

祝好运 ：）

— 戈尔斯
source
2

一个词：TmpDisk

  1. 使用TmpDisk创建1.5Gb RAM磁盘
  2. 将Xcode>偏好设置>位置>派生数据更改为/Volumes/1.5Gb/xcode数据
  3. 享受速度！
— 若阿金·帕兹·卡瓦略
source
3
不，这没有任何改善，对其进行了测试。
— Mihailo Gazda
它确实可以正常工作！在2009 MacBook Pro和2014 11“ Air上都可以。请尝试一下。如果没有发现任何问题，则可能未正确更改路径。为什么？因为写入硬盘甚至SSD都需要花费时间时间。Xcode在编译时写了很多东西，还节省了电池。唯一的缺点是经过几个小时的工作，RAM磁盘已满。然后我必须退出Xcode，删除文件，清空垃圾桶，然后重新开始。更大的RAM磁盘可以解决此问题，但我的计算机只有8Gb
— Joaquim Paz Carvalho
我们不应该将项目文件复制到RAM磁盘以发挥最大作用吗？
— Yaro
@MihailoGazda在活动监视器中Xcode使用了多少RAM？
— 丹尼尔·斯普林格
1

关于“添加更多硬件”方法的快速说明

简介：通过进行重大的硬件升级，我的速度得到了小幅提升

测试：在克隆的Macbook上构建/运行完全相同的项目（唯一的区别应该是它们的硬件）

旧的Macbook Air（1.86GHZ Core 2 Duo仅2GB RAM）与全新的Macbook Pro（2.3GHZ Core i7 8GB RAM）

在IPHONE 3GS
Macbook Air上构建
1: 00-1:15 Macbook Pro〜1：00

=>提速0到0:15

在IPHONE 4S
Macbook Pro上构建〜0 ：35
Macbook Air〜0：50

=>

〜15秒的速度增加**经过部分测试：两台计算机之间的模拟器构建时间之间确实存在显着差异


以我持续的经验..如果对PHONE硬件进行重大更改（例如，在3GS与iPhone 5（或4）上的构建时间）上，您将获得显着增加。.至少以我的经验，限制因素是手机硬件（不是计算机硬件）。

SO ..以获得最快的构建时间
。.option1）编写代码并在快速计算机上的模拟器中运行，或者
option 2）在具有最新iphone的设备上构建

— 用户名
source
1

如果您每次运行时都重新构建整个项目，则可能是XCode 7.0 <= 8.1中的错误给您带来了麻烦。

将用户定义的构建设置HEADERMAP_USES_VFS创建为YES会将Macbook的编译时间从每次75秒减少到25秒。有关更多信息，请参见Xcode 8进行完整的项目重建。

— 塞瑟留斯
source
-1

我切换到5960x CPU的Hackintosh，将其超频至4.4GHz只是为了减少Xcode的编译时间。那是8核心和16线程。一台可以压碎所有Mac的计算机的总成本为3000美元。但是，我已经花了至少10天的时间进行设置，首先是与优胜美地建立了联系。当我无法更新macOS而Xcode需要更新的操作系统时，我有六个月的停机时间。我只是得到它运行塞拉利昂，生活又好起来。

我的2,8 GHz i7双核16 GB RAM MacBook Pro在75秒内完成了我的项目，而Hackintosh在20秒内完成了编译。（项目中的swift，dlib，opencv c ++）

但是最大的问题是Xcode在编译swift时似乎没有使用多个线程。这是瓶颈，希望他们能尽快解决。

— 塞瑟留斯
source
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.