Ответ 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 и используйте его как выделенный или распределенный построитель.
Ошибки файлов
(самоочевидно)