学习理解运行的程序的性能问题与学习debug是一样不可避免的。很多人完成了需求以及功能，但是这个功能的耗时与占用内存全然不管，导致了所写的代码很难受到他人的认可。所以说理解性能问题，能帮助你升华你的代码以及编程水平。
有可能你的客户认为你的一个系统或子系统运行太慢了，或者一跑你的程序就瞬间把cpu的核挤爆了。你要想办法去优化它，去提升它的性能，或者更贴切的说去优化你的逻辑以及算法。
你可能需要去构建一个它为什么慢的思维模型，你可以用一个图表工具或者打印运行时间戳，去发现时间或资源真正被损耗的地方。有可能大部分时间是以某种形式华为费在I/O上。发现昂贵的I/O和昂贵的10%代码是构建思维模型的一个好的开始。打开你windows的任务管理器，可以清晰的看到各个数据以及图表。
计算机系统的性能优很多个维度，很多资源会被消耗。第一种资源是“挂钟时间”，即执行程序的所有时间。记录“挂钟时间”是一件特别有价值的事情。有时候有些东西只是稍微多花费了一点点时间，并且不会引爆什么问题，只有在特定的场景下才会引发crash，所以在你真实要处理的计算机环境中，多一些处理器时间可能会是更好的选择。相似的内存，网络带宽，数据库或其他服务器访问，可能最后都比处理器时间要更加昂贵。
竞争共享的资源被同步使用，一切都到后面都会是资源的争夺，可能导致司索和互斥。死锁是由于不恰当的同步和请求资源导致线程执行能力的丧失。互斥是对于资源访问的不恰当安排。尤其是在多线程高并发的场合，忽略一些东西就会引来很大的麻烦。如果你可以预料到问题可能爆发的点，最好在你的项目开始前就采取措施来衡量线程争抢。及时线程争抢不发发生，对于优先维护他们也是很有帮助的。
比如说对于循环的优化，我相信大都数人循环写完实现功能，一般不会再去思考如何提高他执行循环的效率以及性能。我们总在写循环，总在理所当然的感觉循环不会出问题，但是却并没有以一种高尚的上帝视角来优化，很多时候循环耗时是可怕的，跟递归一般。以下是一段中值滤波的代码，有4个循环，在前面适当的添加宏定义#pragma omp parallel for能够多线程的去执行这个循环，虽然只是一个细微的步骤，但是我觉得这个代码已经往优雅处走。
同时建立合理的预警火灾机制，你可以视情况的严重性添加火灾等级水平，通过邮件或者app及时的抄送给相关的负责人，类似余监视器，把这个监视器打开，你就可以完全可控的掌管大局。
