Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
Logs from bug #44783
Rolf Bjarne Kvinge 2017-01-09 11:25:36 UTC
Your app is quite big, there are in total 256 assemblies referenced by the project, which ends up being 103 assemblies once the Facades are processed and once any assemblies not referenced in code are excluded, and 78 assemblies once the linker has removed unused code.
The top task performance summary shows:
107612.868 ms _CompileToNative 1 calls
47262.822 ms _CodesignNativeLibraries 1 calls
8907.555 ms _CoreCompileInterfaceDefinitions 1 calls
6006.673 ms _CoreCompileImageAssets 1 calls
1m47s doesn't sound all that much to run the managed linker and AOT-compile all 78 assemblies (this is the _CompileToNative task).
47s to sign the native libraries (_CodesignNativeLibraries ) is interesting though, and we might be able to parallelize this to make it faster (and I've filed an enhancement request for this as bug #51298).
For the _CoreCompileInterfaceDefinitions and _CoreCompileImageAssets tasks I'm not sure we can improve much, since those are both just calling Apple command-line tools.
However none of this show the problem you filed the bug about (any small change takes a long time to build), because your log is a rebuild log (the project was cleaned and then built, which will build everything). Could you make a small change, build (not rebuild), and get the resulting log showing the slow build?
I lost my initial comments (rebooting) but Rolf hits the most of the same points.
I would add that using "-fastdev" (the incremental builds options) is something that you should when the linker is disabled (your logs shows it's not). That's both in the option's tooltip and mentioned in 
_With this new build mode, it is best to avoid the linker during development, since this will ensure that your core assemblies remain the same, and reduce the amount of code that needs to be uploaded every time. So you should disable the managed linker, by setting your linker value for development to “Don’t link”._
IOW not doing so will add a lot of changes in the linked BCL which will reduce (or even remove) the advantages of using incremental builds.
Also to restate Rolf's the interesting data (build time) for incremental builds are the "Rebuild" and not the "Build" (from clean) as the later will take a longer time (by design).
Setting to NEEDINFO for Rolf's question:
> Could you make a small change, build (not rebuild), and get the resulting log showing the slow build?
and you should test this with both the linker disable and with your current settings (to compare).
@Allan any news for us?
Where you able to make a small change, build (not rebuild), and get the resulting log showing the slow build?
*** Bug 44783 has been marked as a duplicate of this bug. ***
We have not received the requested information. If you are still experiencing this issue please provide all the requested information and re-open the bug report. That being said I encourage you to try our 15.2 release which includes some build time enhancements