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

Question

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

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

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

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

1. Инкрементное связывание (обычно в сборках отладки) обычно требует гораздо меньше I/O.

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

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

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

Answer 4

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

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

Answer 5

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

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