返回介绍

计时结果

发布于 2024-01-29 22:24:16 字数 1883 浏览 0 评论 0 收藏 0

当上一小节中的脚本在Python 3.0下运行时,我在自己的Windows Vista笔记本上得到了如下的结果——map比列表解析略微快一点,但二者都比for循环要快很多,并且,生成器表达式和函数速度居中。

如果我们研究这些代码及其输出足够长的时间,将会注意到,生成器表达式比列表解析运行得慢。尽管把一个生成器表达式包装到一个list调用中,会使得其功能等同于一个带有方括号的列表解析,两种表达式的内部实现看上去有所不同(尽管我们已经实际地对生成器测试的列表调用计时)。

有趣的是,当我在Windows XP的Python 2.5运行它的时候,结果也是相对类似的——列表解析几乎比对等的for循环语句快一倍,并且当映射abs(求绝对值)这样的一个内置函数的时候,map比列表解析略快。我没有测试生成器函数,并且输出格式也并不是太复杂。

这里列出的实际的Python 2.5测试时间比前面给出的输出要慢两倍,可能是因为我在最近的测试中使用了一款较快的笔记本,而不是因为Python 3.0的改进。实际上,如果从map测试中移除list调用以避免两次创建结果列表的话,这段脚本的所有Python 2.6的结果都比在同样机器上的Python 3.0要快一些(请自行测试以验证)。

如果我们修改这段脚本,在每次迭代上执行一个真正的操作(如加法),而不是调用abs这样的小的内置函数,看看会发生什么(如下代码中省略的部分与前面相同)。

如果需要针对map调用来调用一个用户定义的函数,会使它比for循环语句慢,尽管循环语句的版本的代码更多。在Python 3.0上如下所示。

在一款较慢的机器上,Python 2.5的结果再一次与前面的版本类似,但是,由于测试机器不同,要慢一倍:

由于解释器优化是如此内部化的一个问题,像这样对Python代码进行性能分析是一件非常需要技术的事情。事实上不可能猜测哪种方法会执行的最好,最好的办法是在自己的计算机上、用自己的Python版本,对自己的代码计时。在这种情况下,我们可以肯定地说的是,在这个Python版本下,在map调用中使用一个用户定义的函数至少会因为两种因素中的一种而执行较慢,并且列表解析对于这一测试运行最快。

正如我们前面提到的,性能应该不是你编写Python代码时首要关心的问题——要优化Python代码,你应该做的第一件事情就是不要优化Python代码!首先为了可读性和简单性而编写代码,然后,如果需要的话并且只有在需要的时候,再优化。如果对于你的程序需要处理的数据集合来说,五种替代方案中的任何一种足够快,这将是很好的事情;如果是这样的话,程序的清晰性应该是首要的目标。

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。
列表为空,暂无数据
    我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
    原文