Gru*_*bel 20 build-automation build-process scons
我有一个SCons脚本需要大约10秒才发现没有什么需要重建,这对于本质上相当小的项目感觉非常长.阅读SConscript本身只花了一两秒钟,大部分时间花在:
scons: Building targets ...
Run Code Online (Sandbox Code Playgroud)
步.
我怎样才能知道此时究竟scons
在做什么?还有什么其他一般建议可以写快速SCons脚本?
Cat*_*kul 26
(直接从 http://www.scons.org/wiki/GoFastButton)
命令'scons --max-drift = 1 --implicit-deps-unchanged'将尽快执行你的构建.
要么:
使事情变得更快的另一个技巧是避免在修改共享库但不重建共享库时重新链接程序.请参阅SharedLibrarySignatureOverride
scons md5-sums文件以确定它们已经改变了,所以它几乎是md5sums所有文件.
你可以告诉它只使用时间戳来决定重建什么,而不是每次都要MD5sum所有文件,就像'make'那样,这应该可以加快速度.它可能更脆弱.例如,如果文件在最后一次构建的1秒内发生了变化,那么scons就不会注意到这一点.使用
env.Decider('timestamp-newer')
Run Code Online (Sandbox Code Playgroud)
还有MD5时间戳,它将首先检查时间戳,然后使用Md5比较内容,如果时间戳更新则实际更改.
env.Decider('MD5-timestamp')
Run Code Online (Sandbox Code Playgroud)
另一个加快速度的简单方法是使用-j参数运行并行构建.
scons -j 2
Run Code Online (Sandbox Code Playgroud)
在我的2核盒子上,-j 3通常提供最大的加速.
scons正在做的一些输出可以通过调用scons的--debug参数来完成,请参阅各种选项的联机帮助页.
为了弄清楚为什么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和进入CCFLAGS之间的巨大差异.对于我们的项目有12个外部包含目录(包括boost和python),无所事事的编译从30秒降到3秒 - 加速10倍.
当SCons首先创建时,Environment
它会进行一系列查找以查看可用的工具.DefaultEnvironment
在创建第一个工具之前,您可以通过明确选择工具来避免不必要的检查和加速SCons env
.
DefaultEnvironment(tools=[])
Run Code Online (Sandbox Code Playgroud)
scons --profile
+snakeviz
这个组合准确地向我展示了瓶颈所在。
--profile
以 stdlib 中存在的cProfile
格式输出二进制文件。
snakeviz
然后是一个很棒的可视化工具,可以在 GUI 中快速查看该文件:
scons --profile f.prof
pip install -u snakeviz
snakeviz f.prof
Run Code Online (Sandbox Code Playgroud)
输出如下所示:
您可以将鼠标悬停在每个框上以查看包含该函数的文件的完整路径。
更一般的 Python 上下文中的问题:是否有任何简单的方法来对 python 脚本进行基准测试?
--debug
+ts -s
这并没有解决我的具体问题,但它通常可以给你一些想法:
--debug
标志或所有看起来有趣的标志ts -s
,它显示每行何时出现在标准输出上:如何监控标准输出的每一行是 Bash 中最后一个输出行的时间以进行基准测试?time scons --debug=count,duplicate,explain,findlibs,includes,memoizer,memory,objects,prepare,presub,stacktrace,time |
ts -s | tee f
Run Code Online (Sandbox Code Playgroud)
示例输出摘录显示了我在 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 ...
Run Code Online (Sandbox Code Playgroud)
在 scons 3.0.1、Ubuntu 18.04 中测试。
也可以看看
归档时间: |
|
查看次数: |
11563 次 |
最近记录: |