之前一个朴素算法（效果一般般）耗时150ms.写了一个效果更好的算法，但是性能付出了代价是2200ms，性能差15倍了。
波澜不惊的优化了两天，现在耗时是360ms。
记录一下经验。当然明显经验不是这次发现和清楚的，一直都有否则不叫波澜不惊而是焦头烂额。记录下来以后有新发现时便于补充。
1.手法上：建立全局耗时监测，然后屏蔽一些函数（或直接返回默认值不进行运算），看看耗时的差异是否够大。这样能够快速的评估一个函数耗时的程度，最快的锁定嫌疑犯（就是那些最容易榨出性能红利的地方）
2.放弃系统提供的Pow运算（C#里的Math.Pow，java,swift各个语言都有）来做平方运算，明显乘法完成两个数相乘效率更高，三次方，四次方等同理。
3.放弃不必要的计算，比如利用单调递增函数的特性就得到结论。比如判断两个距离大小。可以判断距离平方的大小。因为计算距离要开方。若仅仅是比大小，没有必要开方来比。
4.看似很小的数学运算重复做，循环次数多了也是性能浪费。所以一个表达式不要计算2次以上。可变量暂存。
5.与或非的条件表达式，可以调整顺序。比如A || B ，如果B的概率更容易true，写B || A将会有惊喜，同理调整if else if块,switch的顺序也定有斩获。
6.除法性能当然没有乘法好，优化数学表达式规避除法运算。
7.放弃int作为key的字典类型，用数组，哪怕造成数组有很多没设值的项。数组的检索速度更快。
8.这已经是常规手段了，在算法设计时就考虑的--"BoudingBox套路"：即先做粗略计算，能减少进入复杂计算的环节。也就节省了性能。两个形状非常复杂的物体的碰撞点在哪里？把他们放进六面体的盒子(BoundingBox)里，先判断盒子是否相撞。
9.找到最底层的运算，这些运算被执行很多次。微小的提升也会全局产生明显收益。放弃函数重载的代码复用，直接计算常见值。放弃代码可读性复用性，为特殊情况提供更高效的算法。
10.函数封装会导致有的逻辑重复执行（最常见的就是参数有效性检查），这些特殊情况下放弃可维护性，让性能极致吧！
11.虽然我其他文章说过了，归类到性能里来说：在解决一个特定问题的算法库中，比较基础的数据结构使用范型（影响到一系列方法和类型也范型化），性能会下降5%这个量级(C#，java这类语言）。应用系统层面不用考虑算法性能 ，毕竟IO网络的耗时大得多，算法性能只是整个体系性能很微小的一部分而已。
