Влияние производительности системы на сборку ссылок 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 и еще несколько дополнительных библиотек для тестирования.
Для настройки системы сборки в этом случае у меня есть два варианта:
- Соедините каждый такой исполняемый файл в системе сборки со своим собственным списком зависимостей библиотеки. (Больно, но, возможно, это можно было бы автоматизировать путем отображения зависимости заголовка -> библиотека.)
- Или просто используйте один и тот же список библиотек для всех тестовых исполняемых файлов и основного исполняемого файла. (Легкий, безболезненный способ).
Что Влияние на производительность системы сборки № 2 «в целом»? Это действительно имеет значение?
Разное:
Это с g ++ (Debian 4.9.1-16) 4.9.1
Решение
Ответ на этот вопрос ДЕЙСТВИТЕЛЬНО зависит от того, что представляют собой эти библиотеки, но в целом я бы сказал, что «вероятно, не окажет большого влияния, если библиотеки не огромные». Проблема в том, что библиотеки ИСПОЛЬЗУЮТСЯ на самом деле, особенно если они большие, потому что весь код из библиотеки должен быть скопирован.
Я просто провел небольшой эксперимент и скомпилировал программу «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 с.
Итак, я бы хотел сохранить простоту и вести единый список библиотек.
Однако я бы добавил, что это зависит от того, где находятся файлы. Если вы ссылаетесь на кучу файлов на очень медленном файловом сервере, может потребоваться немного больше времени, чтобы прочитать «что содержит эта библиотека».
Другие решения