Bug 53210 - Clean builds take a long time
Summary: Clean builds take a long time
Status: RESOLVED ANSWERED
Alias: None
Product: iOS
Classification: Xamarin
Component: Mono runtime / AOT compiler ()
Version: XI 10.4 (C9)
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Zoltan Varga
URL:
Depends on:
Blocks:
 
Reported: 2017-03-09 23:00 UTC by Jim Bennett
Modified: 2017-03-13 14:32 UTC (History)
4 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
Build log (1.24 MB, text/plain)
2017-03-09 23:00 UTC, Jim Bennett
Details


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED ANSWERED

Description Jim Bennett 2017-03-09 23:00:58 UTC
Created attachment 20257 [details]
Build log

If I do a clean build of an iOS app it takes a long time (20 minutes in mobile centre, 7 minutes locally). Incremental builds are fast, but clean builds are slow. It seems to be related to the AOTing of libraries and nuget packages. If I delete everything from bin/obj except the mtouch_cache folder builds are fast.

Log file generated using -v -v -v --time --time attached.
Comment 1 Rolf Bjarne Kvinge [MSFT] 2017-03-10 12:14:19 UTC
You have a lot of assemblies (it looks like ~60 assemblies remain after the managed linker has removed unused code), and AOT-compilation is slow. It's normal that a full build takes a while.

A few tips:

* Don't build for 3 architectures unless you have a good reason to (armv7, armv7s, arm64). For 99% of apps armv7s is unnecessary. This will make the build ~30% faster.
* Don't clean the project :) We implemented incremental builds to solve exactly this problem, but that won't work if you clean your project.
* Enable device-specific builds in the IDE. This will reduce the amount of architectures you build from the IDE to 1 (the one your connected device has).
* Enable the linker for all assemblies, not only SDK assemblies. This will likely remove more code, and there will be less work for the AOT compiler. Some apps don't work correctly when fully linked, in particular apps that use reflection in some way, so take care here.
Comment 2 Jim Bennett 2017-03-11 00:03:36 UTC
Thanks Rolf. I raised this at the request of John Miller after discussing on the slack channel. The problem with incremental builds is sometimes we get weird errors in Visual Studio for Mac about a sealed resource is missing and we have to do a clean build. We also build using Mobile Center which is always a clean build, so it would be nice to speed that up.

I'll remove the armv7s and see how it goes.

Is there a way to cache parts of the mtouch_cache outside of the Obj folder so that we could ship the AOTd binaries for nuget packages with our build to make it faster in Mobile Center?
Comment 3 John Miller [MSFT] 2017-03-13 11:09:19 UTC
Looks like Rolf got a chance to investigate this before me, thanks Rolf!

@Jim,

It sounds like a separate issue should be filed for the sealed resource problem. That might be something that can be fixed.
Comment 4 Rolf Bjarne Kvinge [MSFT] 2017-03-13 14:32:36 UTC
(In reply to Jim Bennett from comment #2)
> The problem with incremental builds is sometimes we get
> weird errors in Visual Studio for Mac about a sealed resource is missing and
> we have to do a clean build.

This sounds like bug #52165.