Влияние производительности системы на сборку ссылок gcc на неиспользуемые библиотеки

У меня есть кодовая база, похожая на следующую:

источники:

src/a/b/c.cpp

и юнит-тесты (на самом деле это исполняемые файлы для буст-юнит-теста):

test/a/b/c_test.cpp

src дерево используется в одной исполняемой цели. тем не мение c.cpp использует только подмножество библиотечных зависимостей этой цели, например -lxиз -lx -ly -lz,

Так же, c_test.cpp компилируется в исполняемый файл теста, который ссылается на c.cpp -lx,c.o и еще несколько дополнительных библиотек для тестирования.

Для настройки системы сборки в этом случае у меня есть два варианта:

  1. Соедините каждый такой исполняемый файл в системе сборки со своим собственным списком зависимостей библиотеки. (Больно, но, возможно, это можно было бы автоматизировать путем отображения зависимости заголовка -> библиотека.)
  2. Или просто используйте один и тот же список библиотек для всех тестовых исполняемых файлов и основного исполняемого файла. (Легкий, безболезненный способ).

Что Влияние на производительность системы сборки № 2 «в целом»? Это действительно имеет значение?

Разное:
Это с g ++ (Debian 4.9.1-16) 4.9.1

0

Решение

Ответ на этот вопрос ДЕЙСТВИТЕЛЬНО зависит от того, что представляют собой эти библиотеки, но в целом я бы сказал, что «вероятно, не окажет большого влияния, если библиотеки не огромные». Проблема в том, что библиотеки ИСПОЛЬЗУЮТСЯ на самом деле, особенно если они большие, потому что весь код из библиотеки должен быть скопирован.

Я просто провел небольшой эксперимент и скомпилировал программу «Hello World» (используя clang++, но он использует тот же компоновщик на сервере, используете ли вы clang++ или же g++, с библиотеками по умолчанию согласно компилятору. Лучшее время заняло 0,232 с (первое время, потому что компилятор должен был считываться с диска, заняло около 2 секунд).

Затем я добавил llvm-config --libs (поэтому библиотеки, которые вам нужны, когда вы используете каркас компилятора llvm). Который превращается в это:

-lLLVMLTO -lLLVMObjCARCOpts -lLLVMLinker -lLLVMipo -lLLVMVectorize -lLLVMBitWriter
-lLLVMIRReader -lLLVMAsmParser -lLLVMTableGen -lLLVMDebugInfo -lLLVMOption
-lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMSelectionDAG
-lLLVMAsmPrinter -lLLVMX86Desc -lLLVMMCDisassembler -lLLVMX86Info
-lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMMCJIT -lLLVMRuntimeDyld -lLLVMLineEditor
-lLLVMInstrumentation -lLLVMInterpreter -lLLVMExecutionEngine -lLLVMCodeGen
-lLLVMScalarOpts -lLLVMProfileData -lLLVMObject -lLLVMMCParser -lLLVMBitReader
-lLLVMInstCombine -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMTarget
-lLLVMMC -lLLVMCore -lLLVMSupport

Это, когда связано, превращает мой проект компилятора в хорошие 100 МБ исполняемого файла.

Разница во времени компиляции с программой «Hello World» составила около 0,04 с.

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

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

1

Другие решения


По вопросам рекламы ammmcru@yandex.ru
Adblock
detector