性能

对用户来说，程序员按是交付软件，提供一个清爽的用户界面，避免系统死机常常比程序的性能更为重要。

性能同代码速度之间存在着很松散的关系。如果只是关注于代码的运行速度，那么这种工作有点顾此失彼。特别要当心放弃其他功能区让代码跑的更快。如果过分强调速度，程序的整体性能常常不升反降。

性能和代码调整

程序需求：在花费时间处理性能问题之前，请想清楚是否在解决一个确实需要解决的问题。

程序设计：程序设计包括了单个程序的主要框架，主要包括程序如何被分解为类。有时程序的设计会使一个高性能的系统难于实现。其他的一些设计则易如反掌。在设计框架时优先考虑整体性能，然后再为单个的子系统、特征和类设置要达到的资源占用目标。

类和子程序设计：设计类和子程序的内部机制为高性能的设计提供了另一个机会。在这一层次的处理中，是否选择了合适的数据类型和算法将对性能产生重要影响。

同操作系统的交互：或许没有注意到程序正同操作系统进行交互，因为有时编译器会生成系统调用，或是程序库使用了未曾想到的系统调用。

代码编译：优秀的编译器能将清晰的高级语言转换为经过优化的机器码。

硬件：有时，最经济也是最有效的提升程序性能的方法就是购买新的硬件设备。

代码调整：是一种对正确代码进行调整实践，它可以使得代码的运行更为高效。

关于代码调整

代码调整的问题在于，高效的代码并不一定就是“更好”的代码。

一些无稽之谈

1、在高级语言中，减少代码的行数就可以提升生成的机器代码的速度，或是减少其资源的占用——错误：抛开代码所具备的美感不谈，高级语言代码行数和程序最终的资源占用和运行速度之间并无必然联系。

2、特定运算可能比其他的快，代码规模也较小——错误：在讨论程序性能的时候，没有“可能”一词的位置。应该实际地测量程序的性能，这样才知道改动到底是提升还是降低了程序性能。在代码调整的时候，应该将根据环境的变化重新进行测试和调整。

3、应当随时地进行优化——错误：一种理论认为，如果使每一个小子程序达到最快和最小，那么程序也一定会非常小并且运行得很快。这样得方法会对微观范围内的优化忙的不可开交，从而对整个系统全局性的重要优化视而不见。

4、程序的运行速度同其正确性同等重要——错误：对于特定类型的项目，运行速度或资源占用是程序员需要重点考虑的问题。这种类型的项目比人们通常所认为的要少，并且随着时间的推移会越来越少。这类项目的性能风险必须通过初期的设计来规避。对其他项目而言，过早地优化则会对软件的整体性能质量产生严重威胁，受到影响的甚至会包括软件的性能。

何时调整代码

程序员应当使用高质量的设计，把程序编写正确。设计的模块化要易于修改，这样可以让后期的维护工作变得很容易。程序正确完成之后，再去检查系统的性能。如果程序运行迟钝，那么在设法让它更快更小。除非你对需要完成的工作一清二楚，否则绝对不要对程序做优化。

常见的低效率之源

1、输入/输出操作，常见程序效率低下的根源之一就是不必要的输入和输出。如果可以选择在内存中处理文件，就不要费力地通过磁盘、数据库，或是跨越网络访问相同的文件。除非程序对空间占用非常敏感，否则数据都应放在内存里面进行处理。

2、分页问题，引发操作系统交换内存页面的运算会比在内存同一页中进行的运算慢许多。

3、系统调用，如果性能对程序来说已经成了一个问题，那么就应找出系统调用到底让你付出了多大的代价。

4、解释型语言，解释型语言似乎应当为系统性能所搜到的损害做出解释，在机器代码创建和执行之前，解释型语言必须要处理每一条程序指令。

5、错误，程序性能的最终麻烦就是代码中的错误。这些错误可能是没有去调试代码、忘了释放内存、数据库表设计失误、轮询不攒在的设备甚至超时，等等。

性能测量

经验对性能优化也没有太大的帮助。一个人的经验或许来源于一台老掉牙的计算机，或许来自于过时的语言或编译器——在任何一种因素发生改变后，所有的经验之谈也会成为狗屁。除非对效果进行测量评估，否则永远也无法确定某次优化所带来的影响。如果没有测量性能变化，那么想当然的优化结果不过是代码变得更晦涩难懂。

性能测量应当精确

应当分配给程序CPU时钟来计算，而不是日期时钟。否则，当系统从自己的程序切换到其他程序的时候，算到某个程序头上的时间实际上是被其他程序占用了。

软件架构————代码调整策略与技术