如何在使用许多extern类型声明时加快编译时间

时间:2011-07-06 18:15:46

标签: c++ xcode compilation extern performance

项目:

xcode 中的C ++编程。我有超过3,000种类型定义,分布在2,000多个.c / .h文件中。每个myType类型都包含字符串描述。我使用脚本在map<std::string, myType>文件中定义了.cpp个3,000多个元素,用于查找myType类型以传递给处理基于{{1}的数据的函数传递给它。由于myType定义分布在2,000多个文件中,因此我使用脚本在头文件中编写每个myType

概述:

(包含extern myType TYPENAME;定义的2,000多个.c个文件)

myType(包含上述文件中每个myTypes.h的所有extern myType语句。

myType(包含上述文件中3,000多个元素的myTypes.cpp

map<std::string, myType>(包括typeProcessor.cpp。使用myTypes.h中定义的地图将字符串与myTypes.cpp匹配。将myType传递给myType中的函数文件如下)

dataProcessor.cpp(根据传递给它的myType处理数据)

问题:

由于我已将myTypes.h添加了3,000多个外部语句,myTypes.cpp添加了3,000多个元素的地图,因此我的项目编译时间从20秒延长到1-1.5小时。

我的问题:

如果没有触及2,000多个文件或接收dataProcessor.cpp的{​​{1}},我该怎么做才能缩短编译时间?

我有过一些想法:

  1. 使用脚本将所有myType定义放入一个大的myType文件中,并删除extern语句。

  2. 使用脚本myTypes.cpp每个包含#include定义的2,000多个文件

  3. 我不太了解编译器,编译时间的主要因素,以及如何编写代码以最小化编译时间。任何帮助表示赞赏。谢谢。

3 个答案:

答案 0 :(得分:0)

无论您为了更好地构建代码都可以做很多事情,为什么不呢

  • 创建公共静态注册功能,例如(typemap.h)

std::map<std::string, myTypeBase>& getGlobalTypeMap();
# define getGlobalTypeMap _once_ in typemap.cpp !

template <class myType>
  registerTypeMapping(std::string name, const myType& instance)
  {
       getGlobalTypeMap().insert(name, instance);
  }
  • 在类型定义的每个.cpp中,调用注册函数。这样一种类型就可以自我注册,并且类型映射不需要“知道所有类型”。这是依赖性的反转,以简单的形式

  • 关键是,没有文件需要包含注册过程的所有类型标题。如果您需要特定于子类型的接口(例如,在地图元素上使用dynamic_cast<subtype>时),您仍需要包含(选定的)类型标题

PS。我假设myType有某种常见的基类型(因为你无法让std::map<std::string, myType>编译,否则就会编译)

更新

修改

  • 是的,您可以使registerTypeMapping成为extern "C"函数(只需将原型编辑为符合C标准)
  • 对于每个type_xx.h/type_xx.c组合,您始终可以生成一个额外的源文件type_xx_register.c,其中包含该类型并注册它。

请注意,这将导致更多来源,但可能会缩短编译时间。特别是,如果你有一个makefile,只有当它的依赖项真正改变时才编译type_xx_register.o目标文件。

这样,只有typemap.h的更改才会导致重新编译所有这些文件。

<子> 简单的

也不是不可能的
$CC type*_register.cpp -o 

_会比单个源的编译更快,包括所有type_xx.h

答案 1 :(得分:0)

由于所有这些文件都没有太大变化(我假设),它要么解析3000+行标题,要么链接会导致编译时间过长。如果它正在解析,预编译的头应该解决,如果它的链接,像Visual Studio的增量链接应该有帮助,但我不认为除了MSVC之外的任何编译器都有这种能力(如果我错了,请纠正我)。

答案 2 :(得分:0)

这可能是阻止对这3,000个文件进行保存的问题

the xcode autosave method

相反

这个autosave off选项(非常愚蠢)在较新版本的xcode中缺失(3.1是一个可靠的xcode),因此所有文件都获得一个新的时间戳,然后相当于一个干净的全部重建。

在命令行上尝试make,不会将文件保存为速度比较。