===============
优化
===============
关于优化。unix的首先要问的是何时不应去优化,然后才是怎么优化的问题。
最有效的优化往往是优化以外的事情,如:清晰干净的设计。
12.1 什么也别做,就站在那儿
程序员工具箱。不做优化的理由是,等硬件几个月后自己升级,留时间出来做更有意义的事,如算法复杂度,干净明晰的设计,结构化,透明可显的设计,等。
12.2 先估量,后优化
如果有真凭实据证明应用程序运行缓慢,这时(仅当这时)才可以考虑优化代码。但实施前,请先估量。
unix有性能剖析程序(profiler):要善加利用。阅读profiler的诊断结果是门学问。
12.3 非定域性之害
最有效的代码优化方法就是保持代码短小简单。永远不要将核心数据结构和时间关键循环抛出缓存。小即是美。指令加载要比执行花费的时间更多。
12.4.1 批处理
持续的服务守护进程是更典型的unix式批处理实例。编写持续的守护进程(与每次启动带来全新会话的CLI服务器相反)有两个理由,一个是显然的,一个有点深奥。显然的理由是控制共享资源的更新。不太明显的理由是,后台程序并不是处理更新,也可因此分期偿还通过多请求读取后台数据库的成本。
--------------------------------
作者特别喜欢分析邮件这种例子,是为什么呢?是因为邮件服务在unix里做得特别出色,以至于成了unix的在网络中的代表,还是作者本身背景是搞网络的,搞邮件的?
包括DNS,P0P3,SMTP,IMAP
XML标记语言:协议语言;
---------------------------------
12.4 鱼和熊掌兼得:低缓存,高吞吐量
结论:总的来说,二进制缓存文件是一项不稳定的技法,应尽量避免。【瓶颈】。认为迫切需求缓存的时候,明智的做法是能够从更深层次来考虑,并问问为什么缓存是必须的。这比将缓存的所有边界条件都考虑到要容易得多。
优化
===============
关于优化。unix的首先要问的是何时不应去优化,然后才是怎么优化的问题。
最有效的优化往往是优化以外的事情,如:清晰干净的设计。
12.1 什么也别做,就站在那儿
程序员工具箱。不做优化的理由是,等硬件几个月后自己升级,留时间出来做更有意义的事,如算法复杂度,干净明晰的设计,结构化,透明可显的设计,等。
12.2 先估量,后优化
如果有真凭实据证明应用程序运行缓慢,这时(仅当这时)才可以考虑优化代码。但实施前,请先估量。
unix有性能剖析程序(profiler):要善加利用。阅读profiler的诊断结果是门学问。
12.3 非定域性之害
最有效的代码优化方法就是保持代码短小简单。永远不要将核心数据结构和时间关键循环抛出缓存。小即是美。指令加载要比执行花费的时间更多。
12.4.1 批处理
持续的服务守护进程是更典型的unix式批处理实例。编写持续的守护进程(与每次启动带来全新会话的CLI服务器相反)有两个理由,一个是显然的,一个有点深奥。显然的理由是控制共享资源的更新。不太明显的理由是,后台程序并不是处理更新,也可因此分期偿还通过多请求读取后台数据库的成本。
--------------------------------
作者特别喜欢分析邮件这种例子,是为什么呢?是因为邮件服务在unix里做得特别出色,以至于成了unix的在网络中的代表,还是作者本身背景是搞网络的,搞邮件的?
包括DNS,P0P3,SMTP,IMAP
XML标记语言:协议语言;
---------------------------------
12.4 鱼和熊掌兼得:低缓存,高吞吐量
缓存操作结果,降低登陆时的延迟。如二进制缓存的使用可以消除有关文本数据库文件解析的开销。一些unix变种已经使用这种技术来加速口令信息的访问速度。
带来的问题:所有涉及二进制缓存的代码必须检查两个文件的时间戳,如果主文本更新了,则必须相应更新缓存。换句话说,主文本的所有变化都必须通过一个能够更新二进制格式的包装器来进行。一旦采用了这种方法,SPOT原则会引导我们发现它所有的缺点。重复的数据表明这种存储不具备经济性——这是一个纯粹的速度优化。但真正的问题是确保缓存和主文本一致的代码非常容易产生漏洞和bug。频繁更新的缓存文件仅仅因为秒级的时间戳分辨率就会导致难以捉摸的竞态条件。
缓存拷贝。主文本的更新模式越复杂,同步代码就越容易产生漏洞。几个unix变种,使用缓存技术来加速关键系统数据库访问速度,以频发系统管理员恐怖事故而臭名昭著,恰反映了这点(这句话,这个例子好用力。表明作者不是空穴来风。表明它是有充分的例证的)。结论:总的来说,二进制缓存文件是一项不稳定的技法,应尽量避免。【瓶颈】。认为迫切需求缓存的时候,明智的做法是能够从更深层次来考虑,并问问为什么缓存是必须的。这比将缓存的所有边界条件都考虑到要容易得多。