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

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

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

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

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

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

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

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

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

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

Компоновщик Visual Studio в значительной степени связан с вводом-выводом, но насколько это возможно, зависит от нескольких переменных.

1. Добавочное связывание (часто встречающееся в сборках отладки) обычно требует гораздо меньше ввода-вывода.

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

3. Если вы используете генерацию кода времени ссылки (LTCG) (распространенную в сборках release), у вас изначально есть все обычные ввод-выводы. Затем компоновщик повторно вызывает компилятор для повторного создания кода для разделов, которые могут быть дополнительно оптимизированы. Эта часть, как правило, гораздо более ресурсоемка для процессора. С другой стороны, я не знаю, действительно ли компоновщик раскручивает компилятор в отдельном процессе и ждет (в этом случае вы все равно увидите низкую загрузку ЦП для процесса компоновщика), или компиляция выполняется в процессе компоновщика (в этом случае вы увидите, что компоновщик проходит через фазы тяжелого ввода-вывода, а затем тяжелого процессора).

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