一次性能优化经历

自从上次修改backlog之后, Silly的IO能力，就一直以少量（约4~6K)的差距落后于redis，却一直找不到原因。 这次打算从头做一次profile来问题到底出在哪。 先用GNU提供的gprof分析一下C代码是否有值得优化的地方，结果发现CPU使用率最高的地方是luaVM内部和malloc/free。 我们所有的业务逻辑全在lua层做的，而IO线程与worker(lua)线程进行交互时是通过malloc来实现的。这几乎表明C代码几乎已经没有优化的余地了。 但是有个好消息，就是gprof不去profile系统调用和so，也许还有机会。 ……

关于CPU分支预测

由于很偶然的原因，这两天瞄了几眼”ZeroMQ”项目，发现项目中使用了’likely/unlikely’这种暗示编译器做分支预测优化的宏（这些宏只是gcc内建函数__builtin_expect的别名)。 其实早在看linux kernel源码时，就不止一次看到这组宏。但是，对此并没有放在心上。仅仅粗略搜了一下，得知‘likely/unlikely这组宏可以向编译器提供分支预测信息，以便编译器可以更好的安排指令顺序来提高效率’就没有再深入下去了。 因为我觉得，这种级别的优化估计能提高个千分之几就……