如何加快MonoTouch的编译时间？ [英] How to speed up MonoTouch compilation time?

问题描述

_{（来源： xamarin.com ）}

了解更多信息，并在 Rolf的帖子中了解如何启用增量构建。。 p>

Evolve 2013视频

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

原始答案

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

托管链接器

对于设备，则全部链接是最快的，其次是 Link SDK 和（结束）不链接。原因是链接程序消除代码的速度比AOT编译器生成代码的速度快（净增益）。此外，较小的.app将更快地上传到您的设备。

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

设备技巧

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




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




• 如果您的.app中捆绑有大量资产，则部署/与您的应用一起上传（每次必须签名，因为它们每次都签名）。我写了一个博客文章关于如何解决此问题的方法-如果您这样做，可以节省很多时间具有大量资产；




• 目标文件缓存是在MonoTouch 5.4中实现的。有些构建的速度会快很多，而其他构建的速度（必须清除缓存时）不会更快（但永远不会慢；-)。 此处）的更多信息。




• 由于符号的原因，调试版本花费的时间更长，运行 dsymutil ，并且由于最终会变大，因此需要更多的时间才能上载到设备。




• 发布版本默认情况下（可以将其关闭）将对程序集进行IL条带化。只需一点时间-可能会在将（较小的.app）部署到设备上时收回。

模拟器技巧

• 就像前面所说的，避免链接，因为这会花费更多时间，并且需要复制程序集（而不是符号链接程序集）；




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

最后，如果不确定时间， ！这意味着您可以在项目中添加-time --time 额外的mtouch参数来查看时间戳每次操作后：-）

It is well known that

If compiling takes even 15 seconds, programmers will get bored while the compiler runs and switch over to reading The Onion, which will suck them in and kill hours of productivity.

Our MonoTouch app takes 40 seconds to compile on Macbook Air in Debug/Simulator configuration.

We have about 10 assemblies in the solution.
We're also linking against some native libraries with gcc_flags.

I'm sure there are ways to optimize compilation time that I'm not aware of, which might have to do with references, linker, whatever.

I'm asking this question in hope that someone with better knowledge than me will compile (no pun intended) a list of tips and things to check to reduce MonoTouch compilation time for debug builds.

Please don't suggest hardware optimizations or optimizations not directly related to MonoTouch.

解决方案

Build Time Improvements in Xamarin.iOS 6.4

Xamarin.iOS 6.4 has significant build time improvements, and there is now an option to only send updated bits of code to the device. See for yourself:

_{(source: xamarin.com)}

Read more and learn how to enable incremental build in Rolf's post.

Evolve 2013 Video

An updated and expanded version of this content can be seen in the video of the Advanced iOS Build mechanics talk I gave at Evolve 2013.

Original Answer

There are several factors affecting build speed. However most of them have more impact on device builds, including the use of the managed linker that you mentioned.

Managed Linker

For devices then Link all is the fastest, followed by Link SDK and (at the very end) Don't link. The reason is that the linker can eliminate code faster than the AOT compiler can build it (net gain). Also the smaller .app will upload faster to your devices.

For simulator Don't link is always faster because there's no AOT (the JIT is used). You should not use other linking options unless you want to test them (it's still faster than doing a device build).

Device tricks

• Building a single architecture (e.g. ARMv7) is faster than a FAT binary (e.g. ARMv7 + ARMV7s). Smaller applications also means less time to upload to device;

• The default AOT compiler (mono) is a lot faster than using LLVM compilers. However the later will generate better code and also supports ARMv7s, Thumb2;

• If you have large assets bundled in your .app then it will take time to deploy/upload them (every time since they must be signed) with your app. I wrote a blog post on how you can workaround this - it can save a lot of time if you have large assets;

• Object file caching was implemented in MonoTouch 5.4. Some builds will be a lot faster, but others won't be (when the cache must be purged) faster (but never slower ;-). More information why this often happens here).

• Debug builds takes longer because of symbols, running dsymutil and, since it ends up being larger, extra time to upload to devices.

• Release builds will, by default (you can turn it off), do a IL strip of the assemblies. That takes only a bit of time - likely gained back when deploying (smaller .app) to the device.

Simulator tricks

• Like said earlier try to avoid linking since it will take more time and will require copying assemblies (instead of symlinking them);

• Using native libraries is slower because we cannot reuse the shared simlauncher main executable in such cases and need to ask gcc to compile one for the application (and that's slow).

Finally whenever in doubt time it! and by that I mean you can add --time --time to your project extra mtouch arguments to see a timestamp after each operation :-)

这篇关于如何加快MonoTouch的编译时间？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！