Cla*_*bel 7 c++ optimization gcc build-time
我有一个自动生成的文件,看起来像这样......
static void do_SomeFunc1(void* parameter)
{
// Do stuff.
}
// Continues on for another 4000 functions...
void dispatch(int id, void* parameter)
{
switch(id)
{
case ::SomeClass1::id: return do_SomeFunc1(parameter);
case ::SomeClass2::id: return do_SomeFunc2(parameter);
// This continues for the next 4000 cases...
}
}
Run Code Online (Sandbox Code Playgroud)
当我像这样构建它时,构建时间是巨大的.如果我使用我的脚本将所有函数自动内联到各自的情况中,则构建时间减少一半.GCC 4.5.0表示当我使用-ftime-report时,大约50%的构建时间被"变量跟踪"占用.这意味着什么?如何在保持从交换机中拔出功能的优越缓存局部性的同时加快编译速度?
编辑:有趣的是,构建时间仅在调试版本上爆炸,根据整个项目的以下分析信息(这不仅仅是有问题的文件,但仍然是一个很好的指标;有问题的文件需要花费最多的时间建立):
如果你很好奇,这里有一些示例do_func,删除了上下文.如您所见,我将问题定义简化为仅显示相关部分.如果您想知道,所有self-> func调用都是对boost :: signal的调用.
static void do_Match_Login(Registry* self, const uint8_t* parameters, uint16_t length)
{
const uint8_t* paramPtr = parameters;
std::string p0 = extract_string(parameters, ¶mPtr, length);
std::string p1 = extract_string(parameters, ¶mPtr, length);
int32_t p2 = extract_int32(parameters, ¶mPtr, length);
uint32_t p3 = extract_uint32(parameters, ¶mPtr, length);
tuple<Buffer, size_t, size_t> p4 = extract_blob(parameters, ¶mPtr, length);
return self->Match_Login(p0, p1, p2, p3, p4);
}
static void do_Match_ResponseLogin(Registry* self, const uint8_t* parameters, uint16_t length)
{
const uint8_t* paramPtr = parameters;
int32_t p0 = extract_int32(parameters, ¶mPtr, length);
std::string p1 = extract_string(parameters, ¶mPtr, length);
array<uint16_t, 3> p2 = extract_vector(parameters, ¶mPtr, length);
std::string p3 = extract_string(parameters, ¶mPtr, length);
uint8_t p4 = extract_uint8(parameters, ¶mPtr, length);
uint8_t p5 = extract_uint8(parameters, ¶mPtr, length);
uint64_t p6 = extract_MUID(parameters, ¶mPtr, length);
bool p7 = extract_bool(parameters, ¶mPtr, length);
tuple<Buffer, size_t, size_t> p8 = extract_blob(parameters, ¶mPtr, length);
return self->Match_ResponseLogin(p0, p1, p2, p3, p4, p5, p6, p7, p8);
}
Run Code Online (Sandbox Code Playgroud)
Dea*_*ing 10
您可以关闭变量跟踪.变量跟踪用于使调试信息更有价值,但是如果这个代码是自动生成的,而你实际上并没有真正调试它那么它就没那么有用了.您只需将该文件关闭即可关闭.
gcc -fno-var-tracking ...
Run Code Online (Sandbox Code Playgroud)
应该做的伎俩.正如我所说,我认为你可以为该文件做到这一点.
归档时间: |
|
查看次数: |
2853 次 |
最近记录: |