背景
组里小伙要对他们的代码进行优化，分析之后，觉得没有什么拖慢性能的代码，于是决定多开几个线程。我得知之后，与他进行了一番对话，终于说服了他在动手优化之前进行充分测量，找出瓶颈再有针对性的优化。
- 对话如下：
- 我：你测量过了嘛？
- 他：什么是测量？
- 我：测量就是对你现有的代码profile，因为经验也好，直觉也罢，都是不可靠的，我们需要证据。从我目前看到的情况来看，我觉得你的数据不足以支持你进行多线程改造。
- 他：我已经看了三遍代码，没有发现优化的地方。
- 我：细节里藏着魔鬼，有时候我们的肉眼，我们的直觉都不可靠。所以我希望你能够测量之后再优化。
- 他：相信我，我觉得多线程是目前最好的解决方案。
- 此时我想，看来光讲道理行不通，得换个方式了，于是说道：好的，假定多线程是最好的解决方案。那么我想知道，你完成你的方案需要多长时间？能跟上我们版本的节奏吗？
- 他犹豫一下说道：大约需要5天吧，放心，我肯定不会拖后腿的。
- 我：好的，我相信你的能力，你肯定能把你的方案做好。但是，我有一个建议。如果我有一个简单的方案，只需要2～3个小时，就能得出结果。也许能解决你的问题，当然，也可能无法解决，你还得做你的多线程。但无论如何，这都算是一个投入非常少的方案，愿不愿意试一下？就算是无法解决，你也不算一无所获，至少掌握了profile的方法。
- 他：好的，试一下吧，如果不行，我还是要弄多线程的。你可要帮我检查一下我写的多线程代码。
然后我把使用文档给他，他照着文档用性能分析工具跑了一下代码，果然找到了瓶颈代码，在一个循环里用一个vector对另外一个vector赋值，如你所知，会产生NNNN多次的构造析构，不慢才怪。修改之后，性能瞬间提升1倍，达成了目标。
坦白说，这是一个很低级的错误，我曾在编码tips里提过多次，然而并没有什么卵用。周围的小伙子们依旧如故，有时候真的挺失望的，一定要通过领导来施压，他们才愿意遵守吗？其实我特别不想通过行政手段来实现目标，低效且低级的手段。当然，这是另一件事，这里就不吐槽了。
过早优化是万恶之源
- Donald Knuth曾经曰过：Don’t Cut Yourself: Code Optimization as a Double-Edged Sword。
- 中文翻译：过早优化是万恶之源。
- 1 究竟要优化什么？
- 2 选择一个正确的优化指标
- 3 优化在刀刃上
- 4 优化层次越高越好
- 5 不要过早优化
- 6 依赖性能分析，而不是直觉
- 7 优化不是万金油
大道理，我们都懂，然而却过不好这一生。这句话我们经常听到，但是在实际工作中却对自己过于自信。
总结
我的优化流程：
- 先对当前代码profile，多采集几次，有足够的样本。
- 针对热点进行分析，尽量用小的改动，实现大的提升。
- 改一点，验证一点，并记录下优化后的数据。如此往复。
PS
- 一直以来，这个小伙都比较傲娇，都不怎么听周围的人的意见，也不怎么听我的（后来才知道，因为之前有人谣传我是91年的，而他是89年的，所以他觉得我比较菜。。。。。）自从这件事之后，他对我的态度明显好多了。码农圈子还是要用技术说话啊，吹的天花乱坠都没用。
- 和别人沟通（也许可以算是辩论）的时候，一定面带微笑，降低语速，摆事实讲道理表明自己的意见。越是意见不一致，就越需要控制语气。舒适的对话，是达成共识的基础。
本博客欢迎转发,但请保留原作者信息
github:codejuan
博客地址:http://blog.decbug.com/