Почему xcodebuild и Xcode 4.2 так медленно?

Ответ 1

У большинства из нас есть три основных варианта:

• Вернитесь к Xcode 3 для ежедневного развития.
• Бросьте на него больше аппаратных средств.
• Измените структуры проектов и примените широкомасштабные трюки для разработки (хотя 20-30 KSLOC невелик).

Самое простое решение - вернуться к Xc3. Да, Xc4 требует намного больше, чем Xc3; память, процессор, дисковое пространство и ввод-вывод. Вам нужно будет определить, где ваши самые большие проблемы - уменьшить количество, которое оно влияет на вас.

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

Переход на Lion + Xc4 более чем удвоил мои требования к оборудованию во всех следующих категориях:

Память

4GB теперь слишком мало для большинства нетривиальных проектов с использованием Xc4 и Lion. Вы все еще можете уменьшить это. У меня 8 ГБ и 10 ГБ на моих основных 2 машинах, Xc4 потребляет все это довольно легко (но мои проекты более сложны, чем ваши, если вы не пишете reeaeaaaally длинные строки). В любом случае, вы можете уменьшить эту проблему:

• Покупка дополнительной памяти.
• Отключить индексирование, если вы создаете огромные проекты в Xcode. Это может сократить потребление памяти Xcode на половину.
• Запуск Xcode в 32 бит. Это не вариант для всех, потому что он будет превышать 4 ГБ в более крупных проектах.
• Уменьшить количество процессов сборки (снова).
• Часто перезагружать Xcode (он не очень хорошо очищает работу после себя).
• Используйте clang как ваш компилятор. Обычно экземпляры Clang используют меньше памяти, чем Apple GCC 4.2.
• Зависимые от нагрузки цели, которые не меняются часто. Пример. В большинстве случаев вам не нужно ежедневно восстанавливать сторонние библиотеки.

CPU

Xcode 4 использует новый (более точный) парсер завершения.

• Снимите диаграммы зависимостей включения и зависимостей. Это очень легко с Obj-C, так как каждый экземпляр Obj-C является указателем. Пример: удаление слабо зависимой структуры включает в себя ваши заголовки.
• Отсоедините свои зависимости и модули. Разрабатывайте библиотеки, но старайтесь сделать их достаточно маленькими и быть в курсе зависимостей, которые они добавят. Пример. Я возглавляю проект, в котором разработчик добавил небольшую функцию (менее 1% приложения), но из-за количества требуемых зависимостей (например, Three20, а затем еще нескольких) двоичный размер конечного исполняемого файла удваивался (и время сборки увеличилось, и парсеру было гораздо больше работы). Большая часть этого не нужна для этой функции - их просто нельзя было удалить, поскольку они были символами objc.
• Уменьшите количество переводов, если это возможно.
• Оптимизируйте использование заголовков префиксов. Вы можете поделиться ими, и вы можете создать их без уважительной причины. Это приносит больше пользы компилятору, чем IDE.
• Минимизировать использование памяти. Работа GC (включая все NSObject allocs) потребляет более 1/3 использования ЦП в крупных проектах, но при этом все еще тратит много времени на сбор, когда его куча огромна.
• Используйте внешние текстовые редакторы и клиенты VC. Довольно очевидно, потому что Xc4 довольно часто отображает SBBOD в больших проектах.
• Минимизировать сложность языка. В порядке сложности: C, ObjC, С++, ObjС++. Чем сложнее перевод, тем больше времени потребуется для анализа и компиляции ваших источников, особенно когда ваши зависимости высоки. Если вы можете легко настроить языковые барьеры в своих зависимостях, сделайте это.
• Вы можете отключить индексирование кода через defaults (также уменьшает потребность в памяти).

Жесткий диск

Это может быть баланс скорости/размера.

• Купите более быстрый (например, SSD).
• Очистка и минимизация зависимостей заголовков.
• Используйте RAM-диск, например Сделать RAM-диск.
• Купите больше памяти. Когда количество Xc4 потребляет, оно заканчивается заменой на диск часто в больших проектах.
• Оптимизируйте свои сборки для правильного использования файлов pch. Это не всегда очевидное направление: я не использовал их в течение нескольких лет в крупных проектах.
• Очистите временные файлы Xcode и Instruments, оставив позади, они могут быть огромными, В некоторых случаях вы можете сохранить их в настраиваемых местах. Если они потребляют десятки ГБ, а ваш строительный каталог совпадает с вашим загрузочным каталогом, то вы будете делать свой диск намного меньше, регулярно читая их.

Сборки

• В Xc4 xcodebuild параллельно с Xcode теперь удваивает работу (по умолчанию делятся отдельно построенные dirs). В Xc3 по умолчанию было построено одно назначение. Проверьте свои настройки. Xcode будет делать тонну избыточного здания, если вы разрешите его (например, одну цель на рабочую область/конфигурацию, а не на модель плоской сборки Xc3).

• Или просто заполните ящик четырехъядерным MacMinis и используйте его как выделенный или распределенный построитель.

Ошибки файлов

(самоочевидно)

Ответ 2

Еще одно возможное решение, которое в некоторых случаях могло бы ускорить Xcode 4: в моем случае основная проблема заключалась в том, что случайно в моем хранилище git было проверено четыре файла из моей сборки/папки. Во время компиляции Xcode замечает, что папка сборки изменилась и запускает git. Так как папка сборки содержит тысячи файлов в моем случае, производительность снизилась. Полное удаление сборки/папки из git (в любом случае не должно было быть проверено) сокращало время компиляции и загрузку системы в массовом порядке. Производительность еще медленнее, чем с Xcode 3, но намного лучше, чем раньше.

Ответ 3

Вы можете включить Distributed Building в настройках XCode и найти подходящего человека, который поможет вам создать ваше приложение, создав вместе с вами кластер компиляции.

Самое забавное, что даже он выключен, ваш компилятор по-прежнему использует разные алгоритмы/механизмы для создания вашего приложения с невероятной скоростью по сравнению с проблемами до;)

Итак, это означает, что они в Apple забыли о одиноких программистах, которые не работают в командах, и поэтому сценарий одиночной компиляции протестирован в версиях 4.0 - 4.2

Ответ 4

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

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

Test: Build/Run точно такой же проект на клонированных 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 между двумя машинами

Ответ 5

Другим виновником медленности являются плагины. Плагин Subversions полностью уничтожил мою производительность Xcode. Я выполнил инструкции в этом сообщении SO, чтобы отключить его. Уф!