不知道大家日常做事有没有和我一样的感受？每当我要做一个project的时候，一开始的时候就会想着怎么做才能使这个project的performance更高，更加robust，当然，这件事每个合格的程序员都会想，然后，我就会想用什么算法、什么架构就能一次性地满足我的以上这些想法，简言之，我就是想“毕其功于一役”，然后就“高枕无忧”！
想法不错，然而现实通常不会按照个人的意志来转移，当然这只是个人经验之谈！
回到题目上来，Call Stack和Performance的关系，也许我们在写Code的时候根本不会去想这件事情。一般情况下，我们总会觉得我们用了一个比较高深的算法和比较复杂的架构，程序的performance就会跟着变好。如果事情发展的顺利，那么我们得到的结果和预期中的可能不会有很大的差距，但是，就像我上面讲的那样，事情通常不会按照我们想要的那样来发展，比如说，每个人写Code都希望最后没有bug，不需要debug，然而事实呢？因此，当事情变得超出我们预料的时候，我们就会手足无错，因为我们用的算法和架构是引用自XXX论文，接着我们的工作就被block住，更糟的是，没人知道这个risk能不能解决，什么时候能解决！
试想一下，如果你的project已经有40多万行代码了，也许在版本演化中代码会发展到50万行，假设你的project提供给enduser一个GUI，那从enduser点击一个button，到最后那个动作真正完成，这其中要经过多少次function call？每一次function call，都会导致stack伸展和回卷。一次stack伸展和回卷可能不会造成很多延迟，但是所有的加起来呢？那就不容你忽视了！
也许有些人还是觉得这个不值得我们如此去care？那我来引用个例子说明一下，大家去看Linux kernel的source code，就会发现有很多函数前多了个“__fastcall”，顾名思义，这类函数要快一些，为什么快？因为这类函数在传递参数的时候要前两个参数传入寄存器中了，因此它要快一些，当然寄存器是很稀有的资源，因此并不是所有的函数都能享有这样的待遇，只有那些调用最频繁的函数才有这样的前缀。还有一个例子，我们经常看到有关Linux kernel的文献中提到INT 80，这时User Space进入Kernel Space的合法通道，但是这个指令有个问题，就是“太慢了”，于是呢Intel引入了一个新指令“sysenter”，这个指令就要比INT 80快些了，当然从单次的调用上来看是没有多少明显的差距的，但是系统在run的时候，这个指令的调用频率，那是“相当高”啊，所以对整个系统来讲，其作用是不容小觑的！这也是宏观和微观的区别！
以上只是讲了下Call Stack与Performance的关系，其实结构和算法只是我们要重点关注的，但还有其他很多细节值得我们去关注！
要想程序能够达到high performance的要求，还得从小处做起！
阅读(826) | 评论(0) | 转发(0) |
