How to speed up MonoTouch compilation time?

Question

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.

Answer 1

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 :-)

Answer 2

This is not really meant as an answer, rather a temporary placeholder until there is a better one.
I found this quote by Seb:

Look at your project's build options and make sure the "Linker behavior" is at the default "Link SDK assemblies".

If it's showing "Don't link" then you'll experience very long build time (a large part of it in dsymutil).

I don't know if it is still relevant though, because MonoDevelop shows a warning sign when I choose this option, and it doesn't seem to affect performance much.

Answer 3

You cannot expect your compiler to be lightninng quick without understanding everything that it is required to do. Larger applications will naturally take longer. Different languages or different compilers of the same language can make a huge difference on how long it takes to compile your code.

We have a project that will take almost 2 minutes to compile. Your best solution is to figure out a way to reduce the number of times you compile your code.

Instead of trying to fix 1 line of code and rebuilding, over and over again. Get a group of people together to discuss the problem. Or create a list of 3 or 4 things you want to work on, complete them all then test.

These are just some suggestions and they will not work in all cases.