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

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

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

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

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

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

Память

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

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

CPU

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

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

Жесткий Диск

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

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

Строит

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

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

Файловые Ошибки

(Пояснение само по себе)