45

众所周知，_

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

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

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

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

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

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

4

3 回答 3

45

Xamarin.iOS 6.4 中的构建时间改进

Xamarin.iOS 6.4 具有显着的构建时间改进，现在可以选择仅将更新的代码位发送到设备。你自己看：

构建时间改进
（来源：xamarin.com）

在Rolf 的帖子中阅读更多内容并了解如何启用增量构建。

进化 2013 视频

此内容的更新和扩展版本可以在我在Evolve 2013上发表的高级 iOS 构建机制演讲的视频中看到。

原始答案

有几个因素会影响构建速度。但是，它们中的大多数对设备构建有更大的影响，包括您提到的托管链接器的使用。

托管链接器

对于设备，Link all是最快的，其次是Link SDK和（最后）Don't link。原因是链接器可以比 AOT 编译器更快地消除代码（净增益）。此外，较小的 .app 将更快地上传到您的设备。

对于模拟器，不要链接总是更快，因为没有 AOT（使用 JIT）。除非您想测试它们，否则不应使用其他链接选项（它仍然比进行设备构建更快）。

设备技巧

  • 构建单一架构（例如 ARMv7）比 FAT 二进制文件（例如 ARMv7 + ARMV7s）更快。更小的应用程序也意味着上传到设备的时间更短；

  • 默认的AOT 编译器（单声道）比使用 LLVM 编译器快很多。但是后者会生成更好的代码，并且还支持 ARMv7s、Thumb2；

  • 如果您的 .app 中捆绑了大型资产，那么使用您的应用程序部署/上传它们（每次都必须签名）将需要时间。我写了一篇关于如何解决这个问题的博客文章——如果你有大量资产，它可以节省很多时间；

  • 对象文件缓存在 MonoTouch 5.4 中实现。一些构建会快很多，但其他构建不会（当必须清除缓存时）更快（但绝不会变慢;-)。更多信息为什么这经常发生在这里）。

  • 调试构建需要更长的时间，因为符号、运行dsymutil以及由于它最终变得更大，需要额外的时间来上传到设备。

  • 默认情况下（您可以将其关闭），发布版本将执行程序集的 IL 条带。这只需要一点时间 - 在将（较小的 .app）部署到设备时可能会恢复。

模拟器技巧

  • 如前所述，尽量避免链接，因为这将花费更多时间并且需要复制程序集（而不是符号链接）；

  • 使用本机库比较慢，因为在这种情况下我们无法重用共享的simlauncher主可执行文件，并且需要让 gcc 为应用程序编译一个（这很慢）。

终于每当有疑问的时候了！我的意思是您可以添加--time --time到您的项目extra mtouch arguments中以在每次操作后查看时间戳:-)

于 2012-12-20T02:14:55.997 回答
4

这并不是真正的答案，而是一个临时占位符，直到有更好的占位符。
我找到了 Seb 的这句话：

查看项目的构建选项并确保“链接器行为”位于默认的“链接 SDK 程序集”中。

如果它显示“不链接”，那么您将经历很长的构建时间（其中很大一部分在 dsymutil 中）。

我不知道它是否仍然相关，因为当我选择此选项时，MonoDevelop 会显示一个警告标志，而且它似乎对性能影响不大。

于 2012-12-19T23:18:59.717 回答
2

如果不了解它需要做的所有事情，你就不能指望你的编译器很快。更大的应用程序自然会花费更长的时间。不同的语言或相同语言的不同编译器可能会对编译代码所需的时间产生巨大影响。

我们有一个编译需要将近 2 分钟的项目。最好的解决方案是想办法减少编译代码的次数。

而不是一次又一次地尝试修复一行代码并重建。召集一群人一起讨论这个问题。或者创建一个包含 3 或 4 个您想要处理的事情的列表，完成它们然后进行测试。

这些只是一些建议，并不适用于所有情况。

于 2012-12-19T23:35:49.450 回答