Как улучшить производительность ссылок для большого приложения C ++ в VS2005 - PullRequest
24 голосов
/ 27 сентября 2008

У нас есть довольно большое приложение на C ++, которое состоит из около 60 проектов в Visual Studio 2005. В настоящее время соединение в режиме Release занимает 7 минут, и я хотел бы попытаться сократить время. Есть ли какие-либо советы по улучшению времени соединения?

Большинство проектов компилируются в статические библиотеки, это облегчает тестирование, поскольку каждый из них также имеет набор связанных модульных тестов. Похоже, что использование статических библиотек не позволяет VS2005 использовать инкрементную компоновку, поэтому даже при включенной инкрементной компоновке происходит полная ссылка каждый раз.

Будет ли иметь какое-то значение использование DLL для подпроектов? На самом деле я не хочу просматривать все заголовки и добавлять макросы для экспорта символов (даже используя скрипт), но если он что-то сделает, чтобы сократить 7-минутное время соединения, я обязательно его учту.

По какой-то причине использование nmake из командной строки немного быстрее, а связывание того же приложения в Linux (с GCC) - намного быстрее.

  • Visual Studio IDE 7 минут
  • Visual C ++ с использованием nmake из командной строки - 5 минут
  • GCC в Linux 34 секунды

Ответы [ 15 ]

1 голос
/ 16 марта 2012

Я решил свою проблему со ссылкой и поделился со всеми вами.

Время ссылки моего проекта составляло 7 минут с / Incremental: нет ссылок (время ссылки 7 минут).

Было 15 минут с / инкремент, (время соединения 7 минут, время встраиваемого манифеста 7 минут). Так что я отключаю инсерментал.

Я обнаружил, что у дополнительных зависимостей есть a.lib, И игнорирую также и определенные библиотеки!

Поэтому я удаляю его из игнорируемых определенных библиотек, включаю / incremental. время первой ссылки нужно 5 минут, но время встраиваемого манифеста не имеет.

Не знаю почему, но пошаговое связывание сработало.

Я откатываю весь код проекта, чтобы найти проблему с помощью библиотеки lib. Если вы делаете все вышеперечисленное, вы можете попробовать мой метод. Удачи!

1 голос
/ 28 сентября 2008

Вы можете попробовать посмотреть на это: http://msdn.microsoft.com/en-us/library/9h3z1a69.aspx

По сути, вы можете запускать сборки проекта параллельно, если у вас несколько ядер.

1 голос
/ 28 сентября 2008

Если вы действительно говорите о времени соединения, то такие вещи, как быстрая сборка решения и Xoreax, не сильно помогут (за исключением Incredilink, что может). Предполагая, что вы действительно измеряете начало ссылки до конца ссылки, я бы посоветовал решить проблему с количеством библиотек, которые у вас есть.

Фаза связи, по крайней мере на начальном этапе, связана с вводом-выводом при загрузке всех объектов и файлов lib. Вы можете оказаться в ситуации, когда у вас есть 60 библиотек вместе с основным проектом большого количества файлов .obj. Я подозреваю, что вы, возможно, просто видите, хотя бы частично, типичную медлительность Windows при загрузке всех этих библиотек и файлов .obj.

Вы можете легко проверить это. Возьмите все эти файлы lib и создайте один единственный файл lib просто в качестве теста. Вместо того, чтобы связываться с 60 из них, связывайтесь с одним и смотрите, куда уходит ваше время. Это было бы интересно.

NTFS очень медленно работает. Это не должно быть 7 м против 32 секунд в Linux медленно, но это может быть частью проблемы. Использование DLL поможет, но вы будете страдать от времени запуска приложения, хотя это будет не так рано. Я был бы уверен, что у вас не будет времени запуска приложения 7 м.

1 голос
/ 27 сентября 2008

Получите более быстрый компьютер с несколькими процессорами и включите параллельные сборки (это может быть включено по умолчанию). Чтобы максимально использовать парализм, убедитесь, что зависимости вашего проекта правильные и у вас нет ненужных зависимостей.

1 голос
/ 27 сентября 2008

60 библиотек для ссылки действительно звучат немного. Это может быть немного экстремальной мерой, но это может радикально ускорить процесс. Создайте новое решение с несколькими проектами и добавьте к ним все источники из существующих проектов. Затем создайте и свяжите их, а оставьте маленькие для тестирования.

...