为什么定期按回车键会大大加快我的代码速度?

时间:2014-02-14 00:07:12

标签: python python-idle

我无意中遇到了让我感到有些困惑的现象。我正在使用IDLE进行一些快速测试,我有一些非常简单的代码(我为了说明而简化了):

from time import clock  # I am presently using windows

def test_speedup():
    c = clock()
    for i in range(1000):
        print i,
    print '=>', clock() - c

现在我像这样运行这个代码(几次,基本结果相同):

# without pressing enter
>>> test_speedup()
0 1 2 3 4 . . . 997 998 999 => 12.8300956124  # the time to run code in seconds

# pressing enter ONLY 3 TIMES while the code ran
>>> test_speedup()
0 1 2 3 4 . . . 997 998 999 => 4.8656890089

# Pressing enter several times while the code ran
>>> test_speedup()
0 1 2 3 4 . . . 997 998 999 => 1.91522580283

我的第一个预感是,也许代码运行得更快,因为当我按下enter键时输出系统可能不需要整理那么多的字符串(每次按下enter键时重新开始)。事实上,输入系统似乎总是在我按下回车后立即获得提升速度。

我也审查了documentation here,但我仍然有点疑惑为什么三个换行符会大大加快速度。

这个问题无疑是微不足道的,除非有人想知道如何在不中止脚本的情况下加速IDLE中的输出系统。不过,我想了解输出系统在这里发生了什么。

(我使用的是Python 2.7.x。)

2 个答案:

答案 0 :(得分:7)

在幕后,IDLE正在模拟Tk小部件顶部的终端,我很确定它最终来自Text

长线的存在会减慢这个小部件的速度。追加长线需要更长时间,而不是追加短线。如果你真的想了解为什么会发生这种情况,你需要查看Tk Text小部件底层的Tcl代码,Tkinter.Text只是一个很薄的包装。

同时,IDLE运行的Tkinter循环做了一些时髦的事情,允许它接受输入而不阻塞循环。当它认为没有其他事情发生时,它有时会阻塞很短的时间,直到它看到输入或Tk事件,并且所有这些短块可能加起来;按Enter键可能只是取消其中一些。

我实际上并不确定这两者中哪一个更相关。你必须使用一个只捕获长行的程序与每个插入换行符的程序(例如10个数字)进行测试,然后看看你获得了多少性能提升。

从Mac上的快速测试开始,原始程序逐渐明显减慢,并且在500和920左右也有两次量子跳跃。所以,每隔333左右进入一次就会有很大意义 - 你可能会避免这两种量子减速。如果我将其更改为只删除逗号,则问题就会消失。

为每个号码打印换行符当然会导致不同的减速,因为这会使终端足够长,需要滚动,增加回滚缓冲区等。我没有看到这个成本在IDLE中,但在Windows命令行上运行相同的东西,你会看到太多新行的问题和IDLE中太少的问题一样糟糕。最好的权衡应该来自“方形” - 数据,或者尽可能接近80列的数据而不会过去。

答案 1 :(得分:0)

我认为这与您用来执行代码的IDE有关。

我已经运行了你的代码(对3.3的语法改动)并且同时执行两次:

999 => 8.09542283367021

编辑:这是使用Python 3.3在库存IDLE中执行的。我通过多次实验发送了输入密钥,并且在控件v。实验中的字符串输出之间没有时间差异。

在预感中,我决定删除一个打印功能并将其压缩成一行。:

print(i, "=>", clock()-c)

这产生了999 => 7.141783124325343

在此基础上,我认为您所看到的时差是由于IDE吸收了更多线程来处理您的代码,从而导致更快的时间。显然,最后的时间是计算和打印for循环的总时间。

为了证实我的怀疑,我决定将所有内容放入元组列表中,然后打印该列表。

def new_speed_test():
    speed_list = []
    c = clock()
    for i in range(1000):
        speed_list.append((i, clock()-c))
    print(speed_list[-1])

输出:(999,0.0005668934240929957)

总结:我的实验证实了你的IDE 处理输出和CPU消耗的方式。