一周前，我面试了一个来自W Labs的Lead Big Data Engineer，问了他一个问题：在一维数组里找满足条件的最长子数组，很不幸，这个Lead Engineer在45分钟内连暴力解法都没有写出来，于是在结束面试前五分钟，我打住了他。
 
他和我说：现在大家都在处理大数据，在Hadoop，Spark上跑程序，我们在这做算法题，优化程序的目的是什么？
 
我当时着急结束面试，草草回答他说：我只是测试你的编程基础。
 
的确，从我13年开始工作到17年这四年，从内存里读1MB数据时间从15us降到6us；机器学习算法从跑在64核CPU变成了$8000的NVIDIA Tesla P100；Amazon服务器带宽从50MB提升到了1GB。

硬件提升如此迅猛，而我们还要在面试的时候进行白板测试，优化算法，提升程序性能做什么？
 
程序的价值是什么？
 
 
有一天我和Uber的工程师
王聊代码，他开篇就说，我加入Uber前没见过那么屎的代码，但就是这个代码撑起了60B的共享经济帝国。
 
由此可见，程序的优美性只是写代码要考虑的一个小问题，最重要的是代码自身的价值。
 
很多时候优化程序性能并不重要。如果你是一个Uber工程师，负责结账功能的系统设计，因为每秒需要处理的请求并不多，所以要解决的问题的难度比微信红包，支付宝要简单不止一个数量级，在这种时候，考虑程序的性能可能是多此一举。
 
著名的Pareto's Law，应用到程序里面就是“20%的代码占用了80%的运行时间”。这个现象在互联网公司可能会更加极端-1%的代码占据了99%的运行时间。
 
说到这，我们可以得出这样一个结论：大部分的代码都是不需要考虑性能优化或者存储优化的。
 
但是！

对于剩下的那么一小部分代码来说，优化是非常重要的，好的工程师能看到优化带去的经济价值，而不是仅仅停留在优化代码的层面上。
 
好的优化是可以量化的
 
 
人们认识问题最直接的方式就是列数据，分析经济价值。
 
从正面来看性能优化是很值钱的，Apple网站上15寸的MacBook Pro有两种型号，2.6G CPU要$2399，2.7G CPU要$2799。除去不到$150的硬盘差价，你需要花10%更多的价格来得到字面上不到4%的性能提升，而且这4%的性能还不一定能从日常使用中体现出来。
 
从反证的角度来看，如果程序性能不重要，我们用更快的电脑更短时间运行完程序并没有额外价值。那么一个拥有16核的服务器应该和一个拥有8核的服务器一样贵，但实际上Amazon的c4.4x价格刚好是c4.2x价格的两倍。
 
现在大家都在使用云服务，每个月的收费是根据你的存储空间使用和CPU消耗使用计算的，你的每一个优化都可以被转化成美金计算出来。Buffer就发表过一篇工程师文章《How We Saved $132k a Year With an IT Infrastructure Audit》谈优化节约了多少经费。
 
另一种衡量方法就是去看用户多喜欢你的产品。长久以来Microsoft的IE浏览器一直是市场霸主，但最近已经被Google的Chrome浏览器后来居上了。在众多人们喜欢用Chrome的原因里，排名第一的就是Chrome的启动速度，网页加载速度远胜于其他浏览器。

著名的独角兽公司Pinterest也发过一篇Blog，谈一系列hack的方法是如何将手机网页加载效率提升了60%，与此同时带来了40%手机网页端用户转化率增长。
 
所以说，天下武功唯快不破。
 
加机器并不是优化性能的良药
 
 
有的不懂技术的人有这样的认识误区，我们可以用加机器，加内存，加CPU这样的方法加速程序，加大吞吐量。但哪怕Amadhl定律不约束并行程序效率，让程序正确的运行在多核，多台机器上也还是一个困难的问题。
 
投入更多的机器是一种提升性能的方法，但是既不便宜，也不简单。
 
考虑这么两种实际情况，一种是在单机上运行并行程序，最初我们可以从1 core变成3 core，将程序的性能提升一倍，但是如果你还想再提升一倍，那可能要16 core，因为程序不得不面对多核带来的额外开销，兼容性和调试的困难性。
 
另一种情况是常见的搜索引擎，当我们使用5台计算机来进行搜索时，整个集群的P95耗时由单机的P99耗时决定，当我们采用10台计算机来搜索时，虽然每台计算机处理的文档减半了，但整个集群的P95耗时变成了单机的P99.5耗时，说不定latency就从100ms变成了200ms。

这样看来，将单线程的代码性能提高一倍在某些情况下意味着更大的经济价值，增加更多的硬件并不是提升性能的魔法，好的工程