优化
关于性能优化,最重要就是如何知道何时不去优化。最有效的优化往往是优化之外的其他事情,比如清晰干净的设计
什么也别做,就站在那儿
别去优化一个工作中的系统,集中精力将时间复杂度或空间复杂度从指数级降到对数或常数集。
另一个建设性的“无为”方式就是不写代码。
先估量,后优化
有真凭实据证明应用程序运行缓慢,这时候(仅当此时)才可以考虑优化代码。但付诸实施前,要先估量。
善用性能剖析程序
非定域性之害
最有效的代码优化方法就是保持代码短小简单
吞吐量和延迟
避免协议的往返,经验法则是尽可能低的时延设计,和忽略带宽成本,带宽问题可以在开发后期通过一些技巧,比如现场压缩协议来解决。
三种常规策略来减少时延
+ 对可以共享启动开销的事务进行批处理 + 允许事务重叠 + 缓存
批操作
重叠操
缓存操作结果
复杂度:尽可能简单、但别简单过了头
复杂度的三个来源
- 代码规模:一般就是代码的函数。
- 实现复杂度:程序员为了理解一个程序从而建立其思维模型并调试该程序的困难程度。
- 接口复杂度:主要是和用户接口的复杂度,比如用户界面,功能,操作等。
面对上面三个复杂度比较陷入三个陷阱:
- manularty(人力尺度)陷阱:主要是为了避免接口复杂度,而把许多底层人物抛给用户。
- blivet(硬撑)陷阱:主要是为了避免代码量复杂度,而使用极端晦涩复杂的算法。
- adhocity(过专用)陷阱:为了避免实现复杂度,不采用统一但是有些复杂的方案,而对每个问题都编写重复,专用的代码。
上一页 Unix编程艺术(六)
下一页 Unix编程艺术(八)