Как я могу ускорить время компиляции при использовании многих объявлений типов extern - PullRequest
1 голос
/ 06 июля 2011

Проект:

C ++ Программирование на xcode .У меня более 3 000+ определений типов и более 2 000+ файлов .c / .h.Каждый тип myType содержит описание строки.Я использовал скрипт, чтобы определить map<std::string, myType> из 3000+ элементов в файле .cpp, чтобы использовать его для поиска типа myType для передачи в функцию, которая обрабатывает данные, на основе которых myType передается ему.Поскольку определения myType распределены по более чем 2000 файлам, я использовал скрипт для записи каждого extern myType TYPENAME; в файл заголовка.

Обзор:

(2000+ .c файлы с myType определениями

myTypes.h (содержит все операторы extern myType для каждого myType в вышеуказанных файлах)

myTypes.cpp (содержитmap<std::string, myType> из 3000+ элементов в вышеуказанных файлах

typeProcessor.cpp (включает myTypes.h. Использует карту, определенную в myTypes.cpp, для сопоставления строки с myType. Пропускает myType к функции из файла ниже)

dataProcessor.cpp (обрабатывает данные на основе переданной ей myType)

Проблема:

Так как ядобавлено myTypes.h с 3000+ внешних утверждений и myTypes.cpp с картой из 3000+ элементов. Время компиляции моего проекта увеличилось с 20 секунд до 1-1,5 часа.

Мой вопрос:

Не касаясь 2000+ файлов или dataProcessor.cpp, получающего myType, что я могу сделать, чтобы сократить время компиляции?

Некоторые мыслиУ меня было:

  1. использовать скрипт, чтобы поместить все определения myType в один большой файл myTypes.cpp и удалить операторы extern. или

  2. используйте сценарий для #include каждого из 2000+ файлов, содержащих myType определений

Я не знаю много о компиляторах, основных факторах времени компиляции и о том, как писать код, чтобы минимизировать время компиляции.Любая помощь приветствуется.Спасибо.

Ответы [ 3 ]

0 голосов
/ 07 июля 2011

Поскольку все эти файлы не сильно меняются (я предполагаю), это либо парсит заголовок строки 3000+, либо ссылки, которые убивают время компиляции. Если это синтаксический анализ, то предварительно скомпилированный заголовок должен решить, что, если он связывает, что-то вроде инкрементного связывания Visual Studio должно помочь, но я не думаю, что какой-либо компилятор, кроме MSVC, имеет такую ​​возможность (поправьте меня, если я ошибаюсь). *

0 голосов
/ 09 сентября 2014

это может быть вопросом предотвращения сохранения этих 3000 файлов

сделать противоположное метод автосохранения xcode

эта autosave off опция (очень глупая) отсутствует в более новых версиях xcode (3.1 - это сплошной xcode), поэтому все файлы получают новую временную метку, а затем эквивалент чистой полной перестройки.

попробуйте make в командной строке, которая не сохраняет файлы для сравнения скорости.

0 голосов
/ 07 июля 2011

Независимо от многих вещей, которые вы могли бы сделать / сделали, чтобы лучше структурировать свой код, почему бы вам не

  • создать публичную функцию статической регистрации, например, (Typemap.h)

.

std::map<std::string, myTypeBase>& getGlobalTypeMap();
# define getGlobalTypeMap _once_ in typemap.cpp !

template <class myType>
  registerTypeMapping(std::string name, const myType& instance)
  {
       getGlobalTypeMap().insert(name, instance);
  }
  • В каждом .cpp для определения типа вызовите функцию регистрации. Таким образом, тип регистрируется сам, и нет необходимости для карты типов «знать все типы». Это инверсия зависимости в простом виде

  • Суть в том, что ни один файл не должен включать все заголовки типов для процесса регистрации. Вам все равно нужно будет включать (выбранные) заголовки типов, если вам нужны интерфейсы, специфичные для подтипа (например, при использовании dynamic_cast<subtype> в элементе карты)

PS. Я предполагаю, что какой-то общий базовый тип для myType (потому что нет способа заставить std::map<std::string, myType> компилировать иначе)

Обновление

Редактировать

  • Да, вы можете сделать registerTypeMapping функцией extern "C" (просто отредактируйте прототип, чтобы он соответствовал C)
  • Для каждого type_xx.h/type_xx.c комби вы всегда можете сгенерировать дополнительный исходный файл type_xx_register.c, который включает просто , который печатает и регистрирует его.

Обратите внимание, что это приведет к большему количеству источников, но, вероятно, сократит время компиляции. Особенно, если у вас есть make-файл и вы компилируете объектный файл type_xx_register.o только тогда, когда его зависимости действительно изменились.

Таким образом, только изменение typemap.h приведет к перекомпиляции всех этих файлов.

Также не исключено, что простой

$CC type*_register.cpp -o 

_ будет быстрее, чем компиляция одного источника, включая все type_xx.h за один раз_

...