代码优化！救命稻草？

不少处于技术测试的游戏，官方都会把玩家对游戏吃硬件的抱怨引导成对下次测试时优化的一种期待。也不乏有公司把程序优化作为一种宣传的手段。这种策略在天骄3，流星蝴蝶剑，剑侠3 这种国内重量级作品的测试宣传中看到影子。但是优化真是如描述的如此信手拈来么，搞得玩家纷纷觉得游戏刚开始测试时效率效果低吃硬件什么的，下次开服时都必定能得到解决。

最近和同事讨论的时候也提及这个问题，按管理的角度看来前期的进度推进肯定远比关注效率来得要紧，所以在是否要静下心来好好做个设计还是先把功能兑现出来以后再慢慢研磨代码的2个不同方案的选择上，领导往往倾向被后一个方案指挥着大脑。在领导和投资者的角度似乎也达成了共识：目前看到的问题都能在游戏上市的时候得到解决，只要把宝押在后期的代码优化上就行，无非时间会花得长点，没事玩家愿意等.......真是如此么，这么多大作回炉了1-2年也没见身影，难道就没有卡在了优化瓶颈上的么。

想起来扯这个原因是引擎组的代码运行效率遇到了瓶颈，用vtune 测了热点，希望能在热点的代码上找到优化的突破口，于是群里有人发了个 <Optimizing software in C++ -- An optimization guide for Windows, Linux and Mac platforms  >  作者是Agner Fog 一个专门研究引擎的大学教授。 不否认这个文档提到的优化方案都表现出作者对系统和编译器充分的造诣，而且提到的方法从数据结构到语句的排列都关注，确实值得花时间读。 但想靠这篇来解决目前的优化瓶颈显然不太可能。

记得有人这么提过 ："代码优化是编辑器的职责，算法优化是程序员的职责，框架优化是架构师的职责"。对此颇为认同。与其天天潜心研究代码级别的优化，考虑如何写出比编译器生成的还给力的asm不如多考虑考虑上层体系的东西；要不软考为啥架构师会比设计师要求掌握的信息更多，因为往往底层解决的问题不及上层解决带来的效率提升来得明显。很多时候同事抱怨，怎么会有人把设计做的如此复杂？简简单单的功能被延伸出如此规模的框架，搞得很多代码不是那么直观。 但很多时候这种看似冗余的复杂度正是为了迎合宏观上的优化，看似直接简单的实现方法往往在宏观上是低效且不易优化的。一直以为：语句的作用< 算法的作用 < 框架的作用。这点在并行开发方式上也得到佐证： 强调并行体系而不是强调并行语句。constexpr 之类keyword的落幕似乎也证明着这点。

阅读优秀的开源代码时往往有这种疑问： 为啥作者兜了这么一大圈来做几行代码就实现的功能呢？ 如果代码总是盯着特定的某种需求实现，那结果很可能是达得到功能需求但达不到运用需求。 抛开架构，抛开算法 专注点放在代码上，永远会受困于局限性。 就像一个小轮子的自行车蹬得快也比不上一个大轮子的以同样力气去蹬跑得远。

如果目前的开发还是以需求兑现来引导并且保持架构不变的前提，估计往后遇到的瓶颈会越来越多。