Environment.Clone窃取启动时间

时间:2014-04-04 15:26:44

标签: performance build environment scons

我们将我们的大型GNU Make构建系统转换为SCons一样好。

除了我们在Environment.Clone()中花费了7秒的启动时间外,其他方法也很顺利。我们正在使用Clone(),因为它具有不修改现有全局状态的良好功能风格。

有没有人想出办法 复制99%的Environment数据永远不会在Clone中被更改?< / p>

在字典中删除未使用的密钥会改善Clone()时间吗?

2 个答案:

答案 0 :(得分:1)

根据您的评论,您可以考虑将您的构建划分为几个较小的构建,每个构建由其单独的SConstruct构建脚本控制,同时维护完整构建的当前SConstruct。我可以想象,改变c ++代码的开发人员只需要构建一次完整的项目来获得非c ++依赖项。然后在处理c ++功能时,他/她只需要构建c ++。同样适用于ada和fortran。

例如,假设您有类似于以下dir结构的内容:

root_dir
|
+--- src_ada
|
+--- src_cpp
|
+--- src_fortran

您可以为每种类型的构建创建一个根级SConstruct,如下所示:

SConstruct             # performs a complete build
SConstruct.ada         # builds just the ada
SConstruct.cpp         # builds just the cpp
SConstruct.fortran     # builds just the fortran

如果正确创建了这些SConstruct脚本,则可能不需要修改子SConscript构建脚本。

您甚至可以通过创建可以采用以下命令行参数的构建包装器脚本来更进一步:

build [complete (default arg) | ada | cpp | fortran]

在内部,脚本会使用适当的SConstruct调用scons,这可能是以下之一:

scons -f SConstruct
scons -f SConstruct.ada
scons -f SConstruct.cpp
scons -f SConstruct.fortran

请注意,选项-f file, --file=file, --makefile=file, --sconstruct=file都是这样做的:让您指定用于构建的SConstruct,如SCons man pages中所述。

答案 1 :(得分:1)

另一种选择是将几个不同的Environment对象传递给不同的子SConscript构建脚本。您可以拥有一个适用于所有不需要克隆的子SConscript脚本的常规构建设置,然后根据其中的需要选择性地传递给辅助SConscript脚本的不同编程语言的不同Environment对象。可能需要克隆这些更具体的Environment对象。

分离像这样的Environment对象可以加快克隆速度,因为只能克隆特定子SConscript脚本所需的信息。