Почему С++-связь практически не использует процессор?

В собственном проекте С++ связь прямо сейчас может занять минуту или две. Тем не менее, за это время процессор падает со 100% во время компиляции до практически нуля. Означает ли это, что привязка - это прежде всего активность диска?

Если да, то это основная область, на которой SSD внесет большие изменения? Но почему не все мои OBJ файлы (или как можно больше) хранятся в ОЗУ после компиляции, чтобы избежать этого? С 4 ГБ оперативной памяти я должен иметь возможность сэкономить много дискового доступа и снова перевести его в CPU, не?

Обновление:, поэтому очевидное продолжение, может ли компилятор и компоновщик VС++ лучше общаться, чтобы упорядочить вещи и сохранить файлы OBJ в памяти, похожие на Delphi делает это?

Ответ 1

Связывание - это, прежде всего, дисковая деятельность. Borland Pascal (назад в день) сохранит всю программу в памяти, поэтому она будет связываться так быстро.

Ваши OBJ файлы не хранятся в ОЗУ, потому что компилятор и компоновщик являются отдельными программами. Если в вашей среде разработки был встроенный компилятор и компоновщик (вместо того, чтобы запускать их как отдельные процессы), он действительно мог бы хранить все в ОЗУ.

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

Ответ 2

Вы можете попробовать установить некоторые из этих утилит RAM-дисков и сохранить каталог obj на диске RAM или даже в целом каталоге проекта. Это должно значительно ускорить его.

Не забудьте сделать это постоянным: -D

Ответ 3

В отладочных сборках в Visual Studio вы можете использовать инкрементную привязку, которая позволяет вам избегать много времени, затрачиваемого на связывание. В основном это означает, что вместо связывания всего файла EXE (или DLL) с нуля он основывается на том, с которым вы связаны в последний раз, заменив только те вещи, которые изменились.

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

Ответ 4

Компонент Visual Studio в значительной степени связан с I/O, но насколько это зависит от нескольких переменных.

Инкрементное связывание (обычно в сборке Debug) обычно требует намного меньше ввода-вывода.
Написание PDB файла (для символов) может потреблять много времени. Это особое узкое место, которое Microsoft нацелило на VS 2010. Запись PDB теперь выполняется асинхронно. Я не пробовал, но я слышал, что он может немного помочь связать время.
Если вы используете генерацию кода времени соединения (LTCG) (общий в релиз-сборках), у вас есть обычный обычный ввод-вывод. Затем компоновщик повторно вызывает компилятор для повторного генерации кода для разделов, которые могут быть дополнительно оптимизированы. Эта часть, как правило, намного более интенсивно требует процессора. Сразу же, я не знаю, действительно ли компоновщик закручивает компилятор в отдельном процессе и ждет (в этом случае вы все равно увидите низкое использование ЦП для процесса компоновщика), или если компиляция выполняется в процессе компоновщика (в этом случае вы увидите, что компоновщик проходит фазы тяжелого ввода-вывода, а затем тяжелого процессора).

Использование SSD может помочь связанным частям ввода-вывода. Также может помочь второй привод. Например, если ваш источник и объекты находятся на одном диске, и вы пишете PDB на отдельный диск, компоновщик должен тратить меньше времени на ожидание записи PDB. Наличие второго вращающегося диска очень помогло моему текущему времени соединения команды.

Ответ 5

Трудно сказать, что именно так лишает компоновщик, не зная, как он взаимодействует с ОС. К счастью, Microsoft предоставляет Process Monitor, чтобы вы могли сделать именно это.

Это помогло мне диагностировать ошибки с IDE Visual Studio и отладчиком без доступа к источнику.