问题标签 [compilation-time]

众所周知，_

如果编译甚至需要 15 秒，程序员会在编译器运行时感到无聊并切换到阅读The Onion，这将吸引他们并扼杀数小时的生产力。

我们的 MonoTouch 应用程序需要 40 秒才能在 Macbook Air 上以调试/模拟器配置进行编译。

我们在解决方案中有大约 10 个程序集。
我们还使用gcc_flags.

我确信有一些我不知道的优化编译时间的方法，这可能与引用、链接器等有关。

我问这个问题是希望比我有更好知识的人会编译（不是双关语）一个提示和检查的列表，以减少调试构建的 MonoTouch 编译时间。

请不要建议硬件优化或与MonoTouch没有直接关系的优化。

除了 之外，是否有-O0可以加快编译时间的选项？

生成的程序是否不会被优化并不重要。实际上，我只想经常快速地对大型 haskell 包进行类型检查。

Flag-fno-code极大地加快了编译速度，但由于该程序使用了 TemplateHaskell，因此无法使用它。

我在 Visual Studio 2012 解决方案中有几个 C++ 项目。这些项目包含大量文件，我使用/MP来加速代码生成。

我想知道是否有办法以类似的方式加速 NVCC。在包含 CUDA 内核的项目中使用 /MP 对编译时间没有任何好处，而且我只能看到一个内核在工作。

所以问题是：如何使用我的多核 PC 来加速 CUDA 编译？

我有一些旧的 C 文件，是在 1999 年为较早的人编写的。由于新的编程技术，代码中有一些无用的部分。但我有一个问题。

• 原始文件 => 640 行 --> 0.448秒
• 新文件 => 581 行 --> 0.493秒

我必须使用带有 O3 优化的 Intel C++ 编译器版本 10。除了编译行中的选项和标志外，编译器配置不可自定义。

原始文件和新文件之间的时间差异可能微不足道，但当外推到 5000 个文件时，它会加起来。

我不认为这是编译器的错。

编辑澄清

我必须优化大量 C 文件的编译时间。这些文件包含许多无用的旧代码（#if 0预处理器代码...）。为了删除所有这些东西，我创建了一个 Python 脚本来检查所有文件并删除所有不需要的代码。

补丁真的很好用。它删除了我想要的所有代码。但是编译时间增加了。我不明白为什么。

编辑#2

我的补丁只删除了由预处理器删除的部分代码，例如#if 0, 和合并循环。15 个循环，其中 1 行且最大值相同，比 1 个循环内 15 行最差。我对大文件（70000 行）进行了大量测试，节省了 60% 的原始编译时间。我不增加复杂性或其他操作。这是代码清除。

我正在使用 Xcode 6 Beta 6。

这是困扰我一段时间的事情，但它已经到了现在几乎无法使用的地步。

我的项目开始有65 个Swift文件和一些桥接的 Objective-C 文件（这真的不是问题的原因）。

似乎对任何 Swift 文件的任何轻微修改（例如在应用程序中几乎不使用的类中添加一个简单的空格）都会导致指定目标的整个 Swift 文件被重新编译。

经过更深入的调查，我发现几乎 100% 的编译器时间是CompileSwiftXcode 在swiftc目标的所有 Swift 文件上运行命令的阶段。

我做了一些进一步的调查，如果我只使用默认控制器保留应用程序委托，编译速度非常快，但是随着我添加越来越多的项目文件，编译时间开始变得非常慢。

现在只有 65 个源文件，每次编译大约需要 8/10 秒。一点也不快。

除了这个，我没有看到任何关于这个问题的帖子，但它是 Xcode 6 的旧版本。所以我想知道我是否是唯一一个在这种情况下。

更新

我在GitHub 上查看了一些 Swift 项目，例如Alamofire、Euler和CryptoSwift，但没有一个项目有足够的 Swift 文件来进行实际比较。我发现的唯一一个大小合适的项目是SwiftHN ，即使它只有十几个源文件，我仍然能够验证相同的东西，一个简单的空间，整个项目需要重新编译，这开始需要很少的时间（2/3 秒）。

与分析器和编译速度都非常快的 Objective-C 代码相比，这真的感觉 Swift 永远无法处理大型项目，但请告诉我我错了。

更新 Xcode 6 Beta 7

仍然没有任何改善。这开始变得荒谬了。由于缺乏#importSwift，我真的不知道 Apple 将如何优化这一点。

更新 Xcode 6.3 和 Swift 1.2

Apple 添加了增量构建（以及许多其他编译器优化）。您必须将代码迁移到 Swift 1.2 才能看到这些好处，但 Apple 在 Xcode 6.3 中添加了一个工具来帮助您这样做：

然而

不要像我一样高兴得太快。他们用来进行增量构建的图形求解器还没有得到很好的优化。

实际上，首先，它不查看函数签名更改，因此如果您在一个方法的块中添加一个空格，则依赖于该类的所有文件都将被重新编译。

其次，它似乎是根据重新编译的文件创建树，即使更改不会影响它们。例如，如果将这三个类移动到不同的文件中

现在如果你修改FileA，编译器显然会标记FileA为重新编译。它也会重新编译FileB（根据对 的更改，这将是可以的FileA），但也FileC因为FileB被重新编译，这非常糟糕，因为FileC从不FileA在这里使用。

所以我希望他们改进依赖树求解器......我已经用这个示例代码打开了一个雷达。

更新 Xcode 7 beta 5 和 Swift 2.0

昨天 Apple 发布了 beta 5，在发行说明中我们可以看到：

Swift 语言和编译器 • 增量构建：仅更改函数体不应再导致依赖文件重新构建。(15352929)

我已经尝试过了，我必须说它现在真的（真的！）运作良好。他们极大地优化了 swift 中的增量构建。

我强烈建议您创建一个swift2.0分支并使用 XCode 7 beta 5 使您的代码保持最新。您会对编译器的增强感到高兴（但是我会说 XCode 7 的全局状态仍然很慢且有问题）

使用 Xcode 8.2 更新

自从我上次更新这个问题以来已经有一段时间了，所以在这里。

我们的应用程序现在大约有 20k 行几乎完全是 Swift 代码，这很不错，但并不出色。它经历了 swift 2 和 swift 3 迁移。在 2014 年中期的 Macbook pro（2.5 GHz Intel Core i7）上编译大约需要 5/6m，这在干净的构建上是可以的。

然而，尽管 Apple 声称，增量构建仍然是一个笑话：

当仅发生很小的更改时，Xcode 不会重建整个目标。(28892475)

显然，我认为我们中的许多人在检查完这些废话后只是笑了（向我的项目的任何文件添加一个私有（私有！）属性将重新编译整个事情......）

我想向你们指出苹果开发者论坛上的这个帖子，其中包含有关该问题的更多信息（以及不时感谢苹果开发者就此事进行的交流）

基本上人们已经想出了一些东西来尝试改进增量构建：

1. 添加HEADER_MAP_USES_VFS项目设置集true
2. Find implicit dependencies从您的方案中禁用
3. 创建一个新项目并将文件层次结构移动到新项目。

我会尝试解决方案 3，但解决方案 1/2 对我们不起作用。

在整个情况下具有讽刺意味的是，在查看有关此问题的第一篇文章时，我们使用 Xcode 6 和我相信 swift 1 或 swift 1.1 代码，当我们达到第一次编译时，现在大约两年后，尽管 Apple 进行了实际改进情况和 Xcode 6 一样糟糕。多么讽刺。

实际上，我真的很后悔为我们的项目选择 Swift 而不是 Obj/C，因为它每天都会带来挫败感。（我什至切换到 AppCode 但这是另一回事）

无论如何，我看到这篇 SO 帖子在撰写本文时有 32k+ 的浏览量和 143 次浏览量，所以我想我不是唯一一个。尽管对这种情况持悲观态度，但坚持下去，隧道尽头可能会有一些曙光。

如果你有时间（和勇气！），我猜 Apple 对此表示欢迎。

直到下次！干杯

使用 Xcode 9 更新

今天偶然发现了这个。Xcode 悄悄地引入了一个新的构建系统来改进当前糟糕的性能。您必须通过工作区设置启用它。

已经尝试过了，但完成后会更新这篇文章。不过看起来很有希望。

我已经自动生成了一个巨大但非常简单的 .cpp 文件。它定义了一个类：

并将以下类型的 10k 行放入构造函数中：

大约 10 分钟前，我已经开始编译这个 .cpp，它仍在进行中。有什么方法可以实现我想要的并减少编译时间？为什么还要花这么长时间？我见过不少有 3k-5k 行常规代码的库，甚至是模板，而且编译速度非常快。

底线 - 我不想将我的数据放入资源文件并解析该文件，我想将数据直接编译成二进制文件。

PS 10k 行文件在调试配置中编译大约需要 30 秒；在发布中，我等了 10 分钟并终止了该过程。

有没有办法输出在 xcode 构建期间编译 swift 文件所花费的时间？

我想从命令行编译以触发与 xcode 相同的构建，但要包括编译每个文件所花费的时间。

显示每个文件的Report Navigator完整构建报告，但没有与之关联的时间范围。

我想减少 Swift 1.2 项目的编译时间，因为清理后大约需要 5 - 10 分钟，或者在严重依赖文件中更改源后需要 3 -5 分钟。

我们正在开发一个C++ 库，目前包含超过 50000 个单独的 .cpp 文件。这些都被编译并归档到一个静态库中。即使使用并行构建，这也需要几分钟。我想减少这个编译时间。

每个文件平均有 110 行，其中包含一个或两个函数。但是，对于每个 .cpp 文件，都有一个对应的 .h 标头，并且这些标头通常包含在许多 .cpp 文件中。例如，A.h可能包含在A.cpp、B.cpp、C.cpp等中。

我首先想介绍一下编译过程。有没有办法找出在做什么上花费了多少时间？我担心打开头文件只是为了检查包含保护并忽略文件而浪费了大量时间。

如果这种事情是罪魁祸首，那么减少编译时间的最佳做法是什么？

我愿意添加新的分组标题，但可能不愿意更改这种多文件布局，因为这允许我们的库也可以根据需要用作仅标题库。

我在 Tizen Project 的 OpenSource code 中发现了可以缩短项目编译时间的模式。它在项目的许多地方都有使用。

作为一个例子，我选择了一个类名ClientSubmoduleSupport。它很短。以下是它们的来源：client_submode_support.h, client_submode_support.cpp。

如您所见，client_submode_support.h它定义了 aClientSubmoduleSupport并且client_submode_support.cpp定义了ClientSubmoduleSupportImplementation为ClientSubmoduleSupport.

你知道那个模式吗？我很好奇这种方法的利弊。

我想懒惰地评估功能。由于计算返回值的成本很高，所以我必须使用 memoization，尤其是对于被调用的子函数，否则计算的时间复杂度会呈指数级增长。我需要编译时的结果。（我正在编写一个库，它根据提供的字符串提供各种编译时模板。）简而言之，我需要在编译时进行记忆。

std.functional.memoizeCT不起作用，所以这是不可能的。DMD 和 LDC 不够聪明，无法记忆纯函数，至少这是我对简单纯函数的实验结果：我测试它是否缓存结果的方式：

使用简单的参数：

使用模板参数：

计时编译（调用 sumN 一次 vs 两次）：

或者

当我在源代码中有两个枚举时，编译时间总是两倍。

有什么方法可以记忆 CT 功能吗？