Как ускорить время компиляции MonoTouch?

Ответ 1

  Улучшения времени сборки в Xamarin.iOS 6.4

Xamarin.iOS 6.4 имеет значительные улучшения времени сборки, и теперь есть возможность отправлять только обновленные биты кода на устройство. Убедитесь сами:

_{(source: xamarin.com)}

Узнайте больше и узнайте, как включить инкрементную сборку в посте Рольфа.

Видео Evolve 2013

Обновленную и расширенную версию этого контента можно увидеть в видео расширенной механики сборки iOS, которое я выступил на Evolve 2013.

Оригинальный ответ

Есть несколько факторов, влияющих на скорость сборки. Однако большинство из них оказывают большее влияние на сборки устройств, в том числе на использование упомянутого вами управляемого компоновщика.

Управляемый компоновщик

Для устройств тогда Link all является самым быстрым, затем следует Link SDK и (в самом конце) Не связывать. Причина в том, что компоновщик может устранить код быстрее, чем компилятор AOT может его создать (чистый выигрыш). Также меньший .app будет загружать быстрее на ваши устройства.

Для симулятора Не связывать всегда быстрее, потому что там нет AOT (используется JIT). Вам не следует использовать другие параметры связывания, если вы не хотите их тестировать (это все же быстрее, чем сборка устройства).

Уловки устройства

• Создание единой архитектуры (например, ARMv7) происходит быстрее, чем двоичный файл FAT (например, ARMv7 + ARMV7). Меньшие приложения также означают меньше времени для загрузки на устройство;

• Компилятор AOT по умолчанию (моно) работает намного быстрее, чем компиляторы LLVM. Однако последний будет генерировать лучший код и также поддерживает ARMv7s, Thumb2;

• Если у вас есть .app, вложенные в ваш .app, потребуется время для их развертывания/загрузки (каждый раз, когда они должны быть подписаны) с вашим приложением. Я написал сообщение в блоге о том, как это можно обойти - это может сэкономить много времени, если у вас большие активы;

• Кэширование объектных файлов было реализовано в MonoTouch 5.4. Некоторые сборки будут намного быстрее, но другие не будут (когда необходимо очищать кеш) быстрее (но никогда не медленнее ;-). Подробнее о том, почему это часто происходит здесь).

• Отладка сборки занимает больше времени из-за символов, запуска dsymutil и, поскольку он становится больше, дополнительное время для загрузки на устройства.

• По умолчанию в сборках выпуска (вы можете отключить его) выполняется сборка IL сборок. Это займет всего лишь немного времени - скорее всего, это вернулось при развертывании (меньшего размера .app) на устройстве.

Трюки с симуляторами

• Как было сказано ранее, старайтесь избегать ссылок, так как это займет больше времени и потребует копирования сборок (вместо символической ссылки);

• Использование нативных библиотек медленнее, потому что мы не можем повторно использовать главный исполняемый файл общего simlauncher в таких случаях и должны попросить gcc скомпилировать его для приложения (и это медленно).

Наконец, когда сомнительное время это! и под этим я подразумеваю, что вы можете добавить --time --time в свой проект extra mtouch arguments, чтобы увидеть метку времени после каждой операции :-)

Ответ 2

На самом деле это не значит, что это ответ, а скорее временный заполнитель, пока не будет лучшего.
Я нашел эту цитату Seb:

Посмотрите на свои варианты построения проекта и убедитесь, что "Linker поведение" находится по умолчанию "Link SDK assemblylies".

Если он показывает "Не ссылаться", то вы получите очень длинную сборку время (большая его часть в дзымутил).

Я не знаю, действительно ли это актуально, потому что MonoDevelop показывает предупреждающий знак, когда я выбираю этот параметр, и он, похоже, не сильно влияет на производительность.

Ответ 3

Вы не можете ожидать, что ваш компилятор будет легко обновляться, не понимая всего, что требуется. Большие приложения, естественно, потребуют больше времени. Различные языки или разные компиляторы одного и того же языка могут иметь огромное значение для того, сколько времени потребуется для компиляции вашего кода.

У нас есть проект, который займет около 2 минут для компиляции. Лучшее решение - выяснить способ сокращения количества раз, когда вы скомпилируете свой код.

Вместо того, чтобы пытаться исправить 1 строку кода и перестроить снова и снова. Объедините группу людей, чтобы обсудить проблему. Или создайте список из 3 или 4 вещей, над которыми вы хотите работать, заполните их все, затем проверьте.

Это лишь некоторые предложения, и они не будут работать во всех случаях.