У большинства из нас есть три основных варианта:
- Возврат к Xcode 3 для ежедневной разработки.
- Добавьте больше оборудования на него.
- Измените структуры ваших проектов и примените уловки для крупномасштабных разработок (хотя 20-30 KSLOC невелики).
Самое простое решение - вернуться к Xc3. Да, Xc4 требует лот больше, чем Xc3; память, процессор, дисковое пространство и ввод / вывод. Вам нужно будет определить, где ваши самые большие проблемы, чтобы уменьшить сумму, которая влияет на вас.
Недавно я купил новый MBP с удвоенными физическими ядрами и удвоенной физической памятью, обновленный до Lion и обновленный Xc4 одновременно. Время компиляции улучшилось , но большая часть остального фактически медленнее и требует гораздо больше ресурсов. Это совсем не то, что можно ожидать от IDE, которая также запрещает несколько открытых проектов, а также использует унифицированное представление рабочей области.
Переход на Lion + Xc4 более чем удвоил мои требования к оборудованию во всех следующих категориях:
Память
4 ГБ сейчас слишком мало для большинства нетривиальных проектов, использующих 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) потребляет более 1/3 использования ЦП в более крупных проектах, но она все равно тратит много времени на сбор данных, когда его куча огромна.
- Используйте внешние текстовые редакторы и клиенты VC. Довольно очевидно, потому что Xc4 довольно часто отображает SBBOD в больших проектах.
- Минимизация языковой сложности. В порядке сложности: C, ObjC, C ++, ObjC ++. Чем сложнее переводы, тем больше времени потребуется для анализа и компиляции ваших источников, особенно когда ваши зависимости высоки. Если вы можете легко установить языковые барьеры в своих зависимостях, сделайте это.
- Вы можете отключить индексацию кода с помощью
defaults (также уменьшает требования к памяти).
Жесткий диск
Это может быть баланс скорости / размера.
- Купите более быстрый (например, SSD).
- Очистить и минимизировать зависимости заголовка.
- Используйте RAM-диск, например Make RAM Disk .
- Купить больше памяти. С количеством, потребляемым Xc4, в больших проектах он часто выгружается на диск.
- Оптимизируйте свои сборки для правильного использования файлов pch. Это не всегда очевидное направление: я не использовал их в течение нескольких лет в крупных проектах.
- Удалите временные файлы, которые Xcode и Instruments оставили, они могут быть огромными . В некоторых случаях вы можете сохранить их в пользовательских местах. Если они потребляют десятки ГБ, а ваш каталог сборки совпадает с вашим каталогом загрузки, то вы заставите свой диск работать намного меньше, регулярно чистя их.
Строит
В Xc4, xcodebuild, параллельный Xcode, теперь удваивает работу (отдельные каталоги сборки по умолчанию). В Xc3 по умолчанию строилась та же цель. Проверьте ваши настройки - Xcode создаст массу избыточного здания, если вы разрешите это (например, одна цель на рабочее пространство / конфигурацию, а не модель плоской сборки Xc3).
Или просто заполните ящик четырехъядерным MacMinis и используйте его в качестве выделенного или распределенного компоновщика.
Ошибка файла
(говорит сам за себя)