Python 高手编程系列八十六：首先要能工作

一个很常见的错误是在编写代码时就尝试优化代码。这是没有意义的因为真正的瓶颈往往位于你从未想到过的地方。应用程序通常由非常复杂的交互组成并且在真正使用它之前我们不可能全面的了解应用程序的功能。当然这不是不去尝试优化一个函数或方法的原因。你应该非常细心并且尽可能降低其复杂性避免无用的重复。但是第一个目标是使它正常工作。优化工作不应该阻碍这个首要目标。对于行级代码Python 的哲学是用一种方法最好是只有一种方法来做一件事。所以只要你坚持使用 Python 化的语法这些语法在第 2 章和第 3 章中提到过你的代码应该是很好的。通常编写较少的代码比编写更多的代码更好更快。在到你的代码正常工作以及你准备好调优之前不要做任何以下这些事情。• 开始编写全局字典以缓存函数的数据。• 考虑使用 C 语言或者混合语言如 Cython外部化一部分代码。• 查找一些进行基本计算的外部库。对于非常专业的领域如科学计算或游戏专业库的使用以及外部化可能从一开始就是不可避免的。另一方面使用像 NumPy 这样的库可以缓解特定功能的开发并且最终产生更简单和更快的代码。此外如果有一个很好的库可以满足你的需求你就没必要重新写一个。例如Soya 3D 是 OpenGL 上的游戏引擎参见 http://home.gna.org/oomadness/en/soya3d/index.html在进行实时 3D 渲染时使用 C 和 Pyrex 进行快速矩阵运算。从用户的角度考虑我见过有团队致力于优化应用程序服务器的启动时间当该服务器启动并运行时它工作地很好。一旦他们完成提速他们把这项工作成果推广给他们的客户。他们有点沮丧他们注意到客户并不太关心这个优化的成果。这是因为加速工作不是由用户反馈而是由开发者的观点驱动的。创建系统的人每天多次启动服务器。所以启动时间对他们来说意味着很多但是对用户来说似乎影响不大。虽然从一个绝对的角度来说让程序启动更快是一件好事但是团队应该小心安排优化工作的顺序并问自己以下问题• 我被要求更快吗• 谁发现程序慢• 它真的很慢还是可以接受• 使它更快地运行需要多少成本值得吗• 什么部分需要很快记住优化是需要成本的并且开发人员的观点对客户来说是没有意义的除非你正在编写框架或库并且客户是开发人员。保持代码的可读性和可维护性即使 Python 试图使常见的代码模式是最快的优化工作可能也会混淆你的代码使代码变得难以阅读。所以在保持代码的可读性和可维护性与为了优化而搞的代码面目全非之间要有一个平衡。当你达到了 90%的优化目标剩下的 10%将使你的代码完全不可读那么你最好停止那里的工作或者寻找其他的解决方案。优化策略如果说你的程序真的有一个速度问题需要解决。不要试图猜测如何使它更快。通常通过查看代码是很难找到瓶颈的所以需要一套工具来找到真正的问题。良好的优化策略可以从 3 个步骤开始。• 找到另外的罪魁祸首确保第三方服务器或资源没有故障。• 扩展硬件确保资源充足。• 编写速度测试创建具有速度目标的场景。找到另外的罪魁祸首通常在生产级别出现性能问题客户会通知你在测试时软件正常工作而现在却不能正常工作了。性能问题可能会发生因为应用程序没有计划在大量用户和增加数据大小的现实世界中工作。但是如果应用程序与其他应用程序交互首先要做的是检查瓶颈是否位于这些交互。例如数据库服务器或 LDAP 服务器会导致一些额外的开销可能会使一切都变慢。应该考虑应用程序之间的物理链接。也许由于错误的配置或者网络拥塞你的应用程序服务器和内网中的另一个服务器之间的网络连接真的很慢。设计文档应提供所有交互和每个连接的性质的设计图从中可以获得系统的整体架构这会有助于解决速度问题。