How to speed up the compilation time of MonoTouch?

Question

it is well known that

If compilation takes 15 seconds, programmers will be bored while the compiler is running and go on to read The Onion , which suck them and kill hours of performance.

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

We have about 10 assemblies per solution.
We also link to some native libraries with gcc_flags .

I am sure that there are ways to optimize compilation time, which I do not know about, which may be related to links, linker, whatever.

I ask this question in the hope that someone with better knowledge than me will compile (not a pun) a list of tips and things to check to reduce MonoTouch compilation time for debug collections.

Please do not offer optimization or optimization of equipment 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 it is now possible to send only updated bits of code to the device. See for yourself:

_{(source: xamarin.com )}

Learn more and learn how to enable incremental builds in Rolf's post .

Video Evolve 2013

An updated and expanded version of this content can be seen in the video of the advanced assembly mechanics of iOS , which I spoke at Evolve 2013 .

Original answer

There are several factors that affect build speed. However, most of them have a greater impact on device assemblies, including the use of the managed linker you mentioned.

Managed Linker

For devices, then Link all is the fastest, then follows the Link SDK and (at the very end) Do not bind . The reason is that the linker can eliminate the code faster than the AOT compiler can create it (net gain). Also a smaller .app will load faster on your devices.

For the simulator Do not always bind faster because there is no AOT (using JIT). You should not use other binding parameters if you do not want to test them (this is still faster than building the device).

Device tricks

• Creating a single architecture (for example, ARMv7) is faster than a binary FAT file (for example, ARMv7 + ARMV7). Smaller applications also mean less time to download to the device;

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

• If you have .app nested in your .app, it will take time to deploy / download them (every time they need to be signed) with your application. I wrote a blog post about how to get around 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 much faster, but others will not (when you need to clear the cache) faster (but never slower ;-). More on why this often happens here ).

• Debugging the assembly takes longer due to the characters running dsymutil and, as it gets bigger, extra time to load onto devices.

• By default, in release builds (you can disable it), builds of IL builds are performed. It only takes a little time - most likely it came back when deploying (a smaller .app size) to the device.

Simulation Tricks

• As mentioned earlier, try to avoid links, as this will take more time and require copying assemblies (instead of a symbolic link);

• Using native libraries is slower because we cannot reuse the main executable file of the general simlauncher in such cases and should ask gcc to compile it for the application (and this is slow).

Finally, when the dubious time is it! and by that I mean that you can add --time --time to your extra mtouch arguments project to see the timestamp after each operation :-)

Answer 2

Actually, this does not mean that it is an answer, but rather a temporary placeholder until it is better.
I found this Seb quote :

Look at your project build options and make sure that “Linker behavior” is by default “Link SDK assemblylies”.

If it shows "Do not reference", then you will get a very long build time (most of it is in the joke).

I do not know if this is really relevant, because MonoDevelop shows a warning sign when I select this option, and it does not seem to have a big impact on performance.

Answer 3

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

We have a project that takes about 2 minutes to compile. The 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 rebuild again and again. Join a group of people to discuss a problem. Or create a list of 3 or 4 things you want to work on, fill them all out, then check.

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