Как уменьшить время сборки/ускорить время компиляции в XCode?

Ответ 1

Часто самое большое, что вы можете сделать, это контролировать включение заголовочных файлов.

Включение "дополнительных" файлов заголовков в исходный код значительно замедляет компиляцию. Это также увеличивает время, необходимое для проверки зависимостей.

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

Ответ 2

Я написал обширное сообщение в блоге о том, как я улучшил цикл разработки iOS в Spotify:

Сброс 50% времени ожидания из цикла iOS Edit-Build-Test

Он сводится к:

1) Остановить создание пакетов dSYM.

2) Избегайте компиляции с -O4 при использовании Clang.

Ответ 3

Лично я переключил компилятор на LLVM-Clang для своих проектов разработки Mac и увидел значительное сокращение времени сборки. Кроме того, компилятор LLVM-GCC, но я не уверен, что это поможет с временем сборки, тем не менее, что вы тоже можете попробовать, если LLVM-Clang не работает для компиляции приложений iPhone.

Я не уверен на 100% LLVM поддерживается для разработки на iPhone, но я думаю, что помню, как читал в новостной ленте, что это такое. Это не оптимизация, которую вы можете реализовать в своем коде, но стоит попробовать!

Ответ 4

Если вы не используете 8 ГБ ОЗУ, обновите его сейчас.

Я только что обновил свой macbook pro с 4 до 8 ГБ. Время моего проекта увеличилось с 2:10 до 0:45. Меня улучшили. Это также делает просмотр веб-страниц для исследования более быстрой и общей производительности Xcode при индексировании и т.д.

Ответ 5

Простой ответ: добавьте еще одну машину с XCode в вашу локальную сеть. XCode включает distcc для распределения распределенных компиляторов. Он может даже использовать Bonjour для поиска других узлов сборки, что упрощает процесс его настройки. Для больших сборок распределение может увеличить скорость, которая почти линейно пропорциональна количеству машин для сборки (2 машины занимают половину времени, три - третье и т.д.).

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

Изменить: К сожалению, похоже, что Apple удалила эту функцию с Xcode 4.3: http://lists.apple.com/archives/xcode-users/2012/Mar/msg00048.html

Xcode 5 имеет версию сервера, которая может выполнять CI, но я сомневаюсь, что это приложит все выгоды для специальных сборок разработчиков. Однако есть некоторые необъявленные функции, которые должны значительно ускорить время сборки.

Ответ 6

Количество потоков Xcode будет использоваться для выполнения задач по умолчанию с тем же количеством ядер, что и ваш процессор. Например, Mac с Intel Core i7 имеет два ядра, поэтому по умолчанию Xcode будет использовать максимум два потока. Поскольку время компиляции часто связано с I/O-привязкой, а не с привязкой к процессору, увеличение количества применений Xcode потоков может обеспечить значительное повышение производительности для компиляторов.

Попробуйте настроить Xcode для использования 3, 4 или 8 потоков и посмотреть, какая из них обеспечивает лучшую производительность для вашего варианта использования.

Вы можете установить количество процессов, которые Xcode использует из терминала, следующим образом:

defaults write com.apple.Xcode PBXNumberOfParallelBuildSubtasks 4

Подробнее см. Пользовательские настройки Xcode.

Ответ 7

Один огромный наконечник, чтобы сократить время компиляции (по крайней мере, для проектов iOS) - установить Параметры сборки/Архитектуры/Только создать активную архитектуру ДА.

Что это делает (особенно с появлением 64-битного iPads/64-битного компилятора), это не строить двоичный файл для архитектур, которые вы в настоящее время не используете.

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

Ответ 8

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

Следует соблюдать осторожность, чтобы избежать проблем, если у вас есть несколько типов компиляции в вашем проекте (например, Obj-C, Obj-С++, С++).

Ответ 9

Эй, я бы рекомендовал вам оптимизировать вашу физическую структуру проекта. Там есть хорошее чтение об этом (по крайней мере, в мире С++), но я делаю objective-C, и те же принципы часто применяются.

Вот отличная статья о оптимизации физической структуры проекта, которая, как правило, улучшает время компиляции Игры изнутри: физическая структура Часть 1

Удачи:)

Ответ 10

Я использовал script, чтобы использовать RAM-диск, а также некоторые "форвардные декларации" для оптимизации моего проекта clean время сборки составляло от 53 секунд до 20 секунд.

У меня возникло соблазн получить Gui в AppStore, но предпочел скорее перейдите в командной строке. Я помещал script как часть репозитория git.

Чтобы просмотреть время сборки, введите это в терминал: "defaults write com.apple.dt.Xcode ShowBuildOperationDuration YES"

Перезапустите Xcode, чтобы заметить время сборки на панели инструментов. (это мое не чистое время сборки с помощью objective-c)

Отрегулируйте script по своему усмотрению. - Обратите внимание, что очистка script папка с производными данными.

#!/bin/sh

#2 GIG RAM
GIGA_BYTES=$((2*1024*1024*1024))

# a sector is 512 bytes
NUMSECTORS=$((${GIGA_BYTES}/512))

#ram disk
mydev=`hdiutil attach -nomount ram://$NUMSECTORS`
newfs_hfs $mydev

# make mount point
MOUNT_POINT=/Users/your_user_name/Library/Developer/Xcode/DerivedData

# ******************************************* 
# ** WARNING - MOUNT POINT WILL BE DELETED ** 
# *******************************************
rm -rf ${MOUNT_POINT}
mkdir -p ${MOUNT_POINT}

# mount
mount -t hfs $mydev ${MOUNT_POINT}
echo unmount $(MOUNT_POINT)

Чтобы увидеть эффект и управлять RAM-диском:

mount                       - see mount points
umount mount_point          - unmount point
diskutil list               - see disks
diskutil eject /dev/diskX   - eject the disk
df -ahl                     - see free space

Примечание: Я по существу использую hdiutil, предоставляемый macOs. Я попытался переключить опцию -kernel (без переключения на диск), но сбой на моей машине, заявив, что он не реализован.

Возможно, новая ОС в ближайшее время увидит еще больше улучшений, так как новая функция копирования файловой системы очень быстрая и, возможно, делает этот резервный script.

Ответ 11

Быстрая заметка относительно подхода "Бросить больше аппаратного обеспечения".

РЕЗЮМЕ: Я испытал небольшое увеличение скорости от создания ОСНОВНОГО обновления аппаратного обеспечения

Тест: создайте/запустите тот же самый проект на клонированных macbooks (где единственное различие должно быть их аппаратным обеспечением)

Старый Macbook Air (1,86GHZ Core 2 Duo ТОЛЬКО 2 ГБ ОЗУ) против Новый Macbook Pro (2.3GHZ Core i7 8GB RAM)

СТРОИТЕЛЬСТВО IPHONE 3GS
Macbook Air 1:00 - 1:15
Macbook Pro ~ 1: 00

= > от 0 до 0:15 с увеличением скорости

СТРОИТЕЛЬСТВО IPHONE 4S
Macbook Pro ~ 0: 35
Macbook Air ~ 0: 50

= > ~ 15 секунд увеличения скорости

** Частично протестировано: там появляется значительная разница между временами сборки для SIMULATOR между двумя машинами

В моем продолжительном опыте.. вы получите значительное увеличение при внесении больших изменений в аппаратное обеспечение PHONE (т.е. время сборки на 3GS против iphone 5 (или 4 в этом отношении)).. по крайней мере, в моем опыте, ограничивающим фактором было аппаратное обеспечение телефона (а не компьютерное оборудование).

SO.., чтобы получить самое быстрое время сборки..
option1) написать код и запустить в simulater на быстром компьютере ИЛИ вариант 2) построить на устройстве с последним iphone

Ответ 12

одно слово: TmpDisk

• Используйте TmpDisk для создания RAM-RAM 1,5 ГБ
• Изменить Xcode > Предпочтения > Местоположение > Производные данные в /Volumes 1.5Gb/xcode данные
• Наслаждайтесь скоростью!

Ответ 13

Если весь ваш проект будет восстановлен каждый раз, когда вы нажмете пробег, возможно, ошибка в XCode 7.0 <= 8.1 дает вам трудное время.

Создание пользовательской настройки сборки HEADERMAP_USES_VFS для YES сокращает время компиляции macbook с 75 секунд каждый раз до 25 секунд. См. Xcode 8 выполняет полную перестройку проекта для получения дополнительной информации.

Ответ 14

Я переключился на Hackintosh с процессором 5960x, разогнанным до 4,4 ГГц, только для сокращения времени компиляции Xcode. Это 8 ядер и 16 потоков. Общая стоимость 3000 долларов за компьютер, который разбивает все маки. Однако я потратил не менее 10 дней на то, чтобы настроить его, сначала с Йосемити. У меня было шесть месяцев простоя, когда я не мог обновить macOS, в то время как Xcode требовал новых os. Я только что запустил sierra, и жизнь снова хороша.

Мой 2,8 ГГц i7 двухъядерный 16 ГБ оперативной памяти MacBook Pro компилирует мой проект за 75 секунд, Hackintosh за 20 секунд. (Swift, dlib, opencv С++ в проекте)

Однако самая большая проблема заключается в том, что Xcode, похоже, не использует несколько потоков при компиляции swift. Это узкое место, я надеюсь, что скоро это исправит.