一、函数调用中编译器的循环代码优化
1.1debug模式
看如下代码:
__int64 mytest(int mv)
{
__int64 icount = 0;
for (int i = 1; i < 1000000; i++)
{
icount += 1;
}
return icount;
}
void main()
{
clock_t start, end;
__int64 mycount = 1;
start = clock();
for (int i = 0; i < 1000; i++)
{
mycount += mytest(6);
}
end = clock();
cout << "耗时(毫秒):" << end - start << endl;
system("pause");
}
结果:
1.2 release模式:
从结果可以看出debug和release相差好大啊!
但是release耗时0毫秒,我觉得很不可思议,肯定没有走1000*1000000次循环。
编译器肯定作了一些优化操作。
我们都知道编译出来的可执行文件一般分为Debug和releas两种版本,在debug版本中,编译器会往里面插入很多信息用于程序调试,而release版本是发布版本,一般用于商业环境中实际使用,编译器不会插入调试信息,而且还会进行优化,执行效率一般比较高。
但是我把循环将6该为i,如下:
for (int i = 0; i < 1000; i++)
{
mycount += mytest(i);
}
结果:
结论:给固定参数时,编译器将这种参数固定的函数调用视为一种不变的表达式。
接下来还是恢复为6,但将调用函数改为:
__int64 mytest(int mv)
{
__int64 icount = 0;
for (int i = 1; i < 1000000; i++)
{
icount += 1;
if (mv == 1000)
{
printf("--\n");
}
}
return icount;
}
结果:
刚才还是0毫秒,现在也变为418了。
二、继承关系深度增加,开销也增加
很多情况下随着继承深度的增加,开销或者执行时间也会增加,这比较好理解,看看如下例子。
class A
{
public:
A()
{
cout << "A::A()\n";
}
};
class B:public A
{
public:
};
class C :public B
{
public:
C()
{
cout << "C::C()\n";
}
};
void main()
{
C c;
system("pause");
}
void main()
{
C c;
system("pause");
}
注意类B,它是没有构造函数的,但是对象c,为了调用类A的构造函数(因为有了就要调用),它必须生成一个类B的构造函数,然后在类B的构造函数中增加调用类A的构造函数的代码。
将断点加在类C的构造函数体内,然后转到汇编可得到如下代码:
可得编译器向类C的构造函数中插入调用类B构造函数的代码。接着查看类B的构造函数的地址(0EE1514h)
然后继续查看jmp后面B::B(0EE6700h)中的地址,如下
从上图红色部分可以看到类B的构造函数中插入了调用类A的构造函数代码,所以调用比较多,性能上必然要差一些。
如果把类A中的构造函数删除了,则有如下代码:
可见没有调用B()的代码了。
三、继承关系深度增加,虚函数导致的开销增加
通过我之前的文章,我们已经知道虚函数的存在会导致编译器产生虚函数表,在多态中调用虚函数时,要通过虚函数表寻找并调用虚函数的,这肯定会增加调用开销。
进一步思考,每个类会有一个虚函数表指针,编译器会在编译的时候往这个构造函数中增加用于给虚函数表指针赋值的代码,所以每多一层继承关系,执行构造函数的时候就会多执行一次对虚函数表指针赋值的代码。