|
“个人电脑的速度在最近几年内增长了好几倍，但应用程序的速度却没太大的变化”--相信包括笔者在内，很多人都有这样的感觉。其中最主要的原因当然是应用程序的功能与处理数据量的急剧增加。不过，笔者认为还另有其它原因。
那就是，一直以来只要应用程序能差不离地在某种速度下运行，开发人员就不太去关注应用程序实际的运行速度。
当然，在那些规定了响应时间的商业应用程序、游戏和控制类应用程序的开发中，现在仍然反复在对其性能进行调试，直到符合标准。这是因为不符合标准的商务系统无法交付使用，反应过于迟钝的游戏也根本没法玩。
但是，对于没有那么明确要求的应用软件，开发人员就很容易以“反正能运行”为借口，不愿意在提高速度上下更多的功夫。
为什么放弃了对高速化的追求
在图形处理LSI的速度提高之后，那些显示效率低的应用程序就变得越来越扎眼了。滚屏时时整个画面都要一行一行地重扫一遍就是其中一个典型的例子。这要是在Windows 3.x时代，这种程序根本就没法用，多亏现在的硬件速度提高了。
在滚屏时，画面上已有的部分使用显存上的数据、只用再绘出需要显示的部分即可，这也是一条基本原则。如果这样还慢的话，还可以采用在主存中以缓冲存储的方式预先存储1页左右的显示内容。当然，这会无端占用那部分的内存，但在用3000日元就能买到256M的DIMM内存的今天，高速化带来的方便性显然更具诱惑。
如果考虑到内存小的环境，可以让用户自己选择显示方式。这里顺便提一句，阿道比公司的Acrobat Reader软件就提供有“页面缓冲存储”的选项，用户就可以设定是否缓存页面。
在速度就是生命的游戏中，也存在着只在乎游戏的进行速度，而对启动时间、任务读取时间却毫不介意的情况。在最近推出的游戏中，多数在安装时大多可让用户选择是将接近1G的任务数据全部复制到硬盘上，还是游戏时从CD-ROM读取。
在选择后者的情况下，每当反复操作同一任务时都要从CD-ROM上读取数据，因此每次都要等待几秒到几十秒的时间。当一个任务老是执行不完时，相信有不少用户会生出一肚子怨气。想当初，CD-ROM游戏刚刚问世时，不少游戏开发商就曾致力于将游戏进行中的任务数据缓存到硬盘上，但目前的进展却令人感到遗憾。
当然，上面所举的例子在实际应用时并不是多么严重的问题，但确确实实给用户的使用带来了不便。
只需一点点努力就能程序就会更快
程序提速的代价往往是将源代码变得晦涩难懂，或者难以重复利用和维护。因此在有关编程方法的书籍里，大都主张“比起编写速度更快一些的代码，更应重视可读性与重复利用性”。不过希望大家注意，这些论调大多是在推崇速度至上主义的时代产生的。
当时的计算机如果编写了效率低的代码，就无法以完全符合要求的速度运行，而且在按照CPU时间收费的系统中，实际运行速度就直接意味着成本的高低。因此对当时的程序员来说，“编写快速程序”便成为首要任务。之所以当时许多人提出比起速度更应重视可读性，充其量也只是为了防止程序员们过渡偏重于速度。
但是，现在“比起速度更应重视可读性”这一论点开始独步程序界，而有关提高程序速度的话题却减少了，其中突出的问题是，程序员很少在重视实际运行速度的前提下编写代码。他们只注重如何实现程序的功能，而很少考虑程序的运行速度。在调试时，大多也以程序速度并非慢得无法忍受为借口，不再在速度上多费时间。其结果就是，嵌有很多效率低下代码的程序充斥在市场上。
笔者也并非主张所有的代码都要拼命地调试。只不过是希望能比现在稍微重视一下速度问题而已。
根据90-10(80-20)法则，应用程序实际运行时间的90(80)%，被10(20)%的代码占有。只要对这关键的10%稍加注意，就有可能大幅度提高应用程序的速度。剩下的部分就是象以往一样重视其可读性与重复利用性来进行编程就行了。
那么，这瓶颈部分究竟该如何解决呢？首先要明确的是，对效率低下的代码与不合常理的代码，换言之，也就是让有经验的程序员认为是“愚蠢的”的代码要进行彻底修改。具体地讲，前面提到的滚屏时全部图像都要改写就是一个例子。
另外，笔者在采访中也曾听到过，“最近的程序员中，有很多并不在意数据库访问时光标、锁定的种类(读取专用/写入)以及时机”的说法。笔者如果在编辑杂志样本时就使用这样的程序的话，运行当然不成问题，但在速度方面肯定要大打折扣了。如果还保留这样的代码，根本无法提高其可读性与重复利用性，实在是有百害而无一利。
还有一点，就是要充分认识提高速度的优点与提速所需的时间与人力资源成本，从而有平衡地达到高速化。调试所花费的时间及其效果与Debug(纠错)等工作一样应绘制出对数曲线。要想使速度已经非常高的代码进一步提速是十分困难的事，但对于那些没有考虑速度的代码来说，只需稍加变动即可成倍地提高速度。
最后再次提醒，CPU的速度在18个月里才增加1倍，但速度慢的代码与速度快的代码间的速度差，可以是几倍甚至几十倍！
| 
