У меня есть сценарий SCons, который занимает около 10 секунд только для того, чтобы выяснить, что ничего не нужно перестраивать, что кажется ужасно долгим для того, что по сути является довольно небольшим проектом. Чтение самого SConscript занимает всего секунду или две, большую часть времени тратится на:
scons: Building targets ...
шаг.
Как я могу узнать, что именно scons делает в этот момент? И какой еще общий совет можно дать по написанию быстрых SCons-скриптов?
scons --profile + snakeviz
Эта комбинация показала мне, в чем именно заключалось узкое место.
--profile выводит двоичный файл в формате cProfile, который присутствует в стандартной библиотеке.
snakeviz — отличный инструмент визуализации для быстрого просмотра этого файла в графическом интерфейсе:
scons --profile f.prof
pip install -u snakeviz
snakeviz f.prof
Вывод выглядел так:
и вы можете навести курсор на каждое поле, чтобы увидеть полный путь к файлу, содержащему функцию.
Вопрос в более общем контексте Python: любой простой способ сравнить скрипт Python?
--debug + ts -s
Это не решило мою конкретную проблему, но часто может дать вам некоторые идеи:
--debug или все, что покажется интереснымts -s, который показывает, когда каждая строка появляется на стандартном выводе: -stdout-was-the-last-output-line-in/49797547#49797547">Как отслеживать, сколько времени каждая строка stdout была последней строкой вывода в Bash для бенчмаркинга?time scons --debug=count,duplicate,explain,findlibs,includes,memoizer,memory,objects,prepare,presub,stacktrace,time |
ts -s | tee f
Пример выдержки из вывода, который показал, где у меня был огромный временной разрыв между 2 и 10 секундами, на котором я пытался сосредоточиться:
00:00:02 SConscript:/data/gem5/master3/build/ARM/sim/power/SConscript took 1.556 ms
00:00:02 dup: relinking variant 'build/ARM/sim/probe/SConscript' from 'src/sim/probe/SConscript'
00:00:02 Building build/ARM/sim/probe/SConscript with action:
00:00:02 UnlinkFunc(target, source, env)
00:00:02 Building build/ARM/sim/probe/SConscript with action:
00:00:02 LinkFunc(target, source, env)
00:00:02 SConscript:/data/gem5/master3/build/ARM/sim/probe/SConscript took 0.401 ms
00:00:10 SConscript:/data/gem5/master3/build/ARM/tests/opt/SConscript took 98.225 ms
00:00:10 SConscript:/data/gem5/master3/build/ARM/SConscript took 8885.387 ms
00:00:10 SConscript:/data/gem5/master3/SConstruct took 9409.641 ms
00:00:10 scons: done reading SConscript files.
00:00:10 scons: Building targets ...
Протестировано в scons 3.0.1, Ubuntu 18.04.
См. также
(украдено непосредственно с сайта http://www.scons.org/wiki/GoFastButton)
Команда 'scons --max-drift=1 --implicit-deps-unchanged' выполнит вашу сборку максимально быстро.
OR:
Еще одна хитрость, позволяющая ускорить работу, заключается в том, чтобы избегать повторной компоновки программ, когда разделяемая библиотека была изменена, но не перестроена. См. раздел SharedLibrarySignatureOverride.
scons файлы md5-sums, чтобы выяснить, были ли они изменены, так что md5суммирует практически все ваши файлы.
Вы можете указать ему использовать только временные метки, чтобы решить, что перестраивать, и не нужно каждый раз MD5суммировать все файлы, как это делает make, что должно ускорить процесс. Он может быть более хрупким. например если файл изменился в течение 1 секунды с момента его последней сборки, scons этого не заметит. Использовать
env.Decider('timestamp-newer')
Существует также метка времени MD5, которая сначала проверяет метку времени, а затем сравнивает содержимое с помощью Md5, если оно действительно изменилось, если метка времени новее.
env.Decider('MD5-timestamp')
Еще один простой способ ускорить процесс — запустить параллельную сборку с параметром -j.
scons -j 2
На моем 2-ядерном компьютере -j 3 обычно дает наибольшее ускорение.
Некоторый вывод о том, что делает scons, можно сделать с помощью аргумента --debug для вызова scons, см. справочную страницу для различных параметров.
Сделал немного проб и ошибок, чтобы выяснить, почему SCons работает медленно, некоторые выводы на данный момент (точные результаты, конечно, будут варьироваться в зависимости от структуры и сложности сценария SCons):
CacheDir() не оказывает заметного негативного воздействия.Decider() имеет очень незначительное влияние, с которым не стоит заморачиваться.variant_dir/VariantDir() увеличивает время сборки примерно на 10%.SConstruct занимает около 10% всего вызова scons.Возможные решения:
scons -u вместо scons -D).SConscript необязательными, чтобы они перестраивались только при ручном вызове.Используйте флаг компилятора -isystem для включения библиотеки вместо -I, одно только это изменение сократило время сборки с 10,5 до 6 секунд для меня, это можно легко выполнить с помощью небольшого вызова sed:
env.ParseConfig('pkg-config --cflags --libs gtkmm-2.4 | sed "s/-I/-isystem/g"')
Не совсем уверен, почему это работает, я предполагаю, что это сокращает зависимости, которые выводит gcc, и, таким образом, в свою очередь, зависимости, которые отслеживает scons.
Использование CacheDir() и scons -j N, конечно же, также настоятельно рекомендуется, но только ускоряет фактическую сборку, а не оценку самого скрипта SCons.
Перемещение сторонних включений из CPPPATH в CFLAGS имело огромное значение. Для нашего проекта с 12 внешними включаемыми каталогами (включая boost и python) компиляция бездействия сократилась с 30 до 3 с — ускорение в 10 раз.
Когда SCons создает первый Environment, он выполняет ряд запросов, чтобы узнать, какие инструменты доступны. Вы можете избежать ненужных проверок и ускорить SCon, явно выбрав инструменты в DefaultEnvironment перед созданием своего первого env.
DefaultEnvironment(tools=[])
Добавьте в свой SConscript что-то вроде
if 'explain' in GetOption("debug"):
Progress('Evaluating $TARGET\n')
и беги с --debug=explain. Вы увидите, на что SCons тратит время на оценку
