Windows 中 Python 的缓冲输出与非缓冲输出

prr*_*rao 3 python notepad++ unbuffered-output nppexec

我使用 NppExec/Notepad++ 运行 Python 脚本,并在运行时连续刷新输出缓冲区,以使用print语句更新控制台窗口(默认缓冲输出仅在脚本执行完成后显示所有打印语句)。

链接显示您所需要做的就是使用该命令python -u来获取无缓冲的输出。无论使用什么编辑器,对所有Python 脚本使用此执行模式是否有缺点?我不清楚缓冲输出和无缓冲输出之间的区别。

编辑:我包含了这个小的 Python 计时器脚本作为示例:

#!usr/bin/env python
import time
import threading
import sys

class Timer(threading.Thread):
    def __init__(self, seconds):
        self.runTime = seconds
        threading.Thread.__init__(self)
    def run(self):
        counter = self.runTime
        for sec in range(self.runTime):
            print counter
            time.sleep(1.0)
            counter -= 1
        print "Done."

if __name__ == '__main__':
    t = Timer(10)
    t.start()
Run Code Online (Sandbox Code Playgroud)

在这种情况下,缓冲和无缓冲输出在效率方面有多大差异?

mgi*_*son 5

缓冲输出意味着计算机将输出假脱机到内存中的某个位置,直到累积到一定数量。然后它立即写入整个块。这比使用无缓冲输出更有效,无缓冲输出在您请求写入时立即写入输出。

缺点是您的程序运行速度会慢一点(或慢很多),具体取决于您编写的输出量。如果它们是不执行太多输出的简短程序,您不太可能注意到差异......

编辑

缓冲输出与非缓冲输出不仅仅是一个Python问题。相同的概念(和术语)也适用于其他语言。在较低级别的语言中,它在某些方面变得更加重要 - 如果我使用缓冲输出在 C 程序中写入消息,然后我的程序由于编程错误而终止,则错误之前假脱机的任何数据,但不是写入磁盘的内容丢失。这不是一个问题,因为让 python 解释器在错误时中止是相当困难的——即使你的代码很糟糕,解释器最终仍然会清理干净......(除非你向它发送一个终止信号或者其他的东西)...


sar*_*old 5

我可以想到两个缺点,但它们的重要性取决于您的需求:

  1. 无缓冲的读写可能会明显变慢;如果您一次写入一行文本文件,您的代码可能会进行数百次系统调用来要求操作系统写入该文件。根据写入磁盘的速度,这甚至可能意味着需要从磁盘重新读取文件的最后一个块,以便使用新的最后一行重新保存文件。(这种情况可能很少见;但更多的系统调用几乎总是导致速度变慢的原因。)

    下面简单演示一下系统调用次数对写入速度影响较大:

    $ cat initrd.img-2.6.38-8-generic > /dev/null
    
    Run Code Online (Sandbox Code Playgroud)

    第一行确保文件位于缓存中,因此仅测量输出速度。

    $ dd if=initrd.img-2.6.38-8-generic of=/tmp/out bs=16 oflag=dsync
    ^C262766+0 records in
    262766+0 records out
    4204256 bytes (4.2 MB) copied, 50.7754 s, 82.8 kB/s
    
    Run Code Online (Sandbox Code Playgroud)

    我放弃了等待——进展太慢了。这是一次“无缓冲”地将 16 个字节写入磁盘,并确保每次写入成功后再继续下一次写入。(这就是dsync——稍后会详细介绍。)

    $ dd if=initrd.img-2.6.38-8-generic of=/tmp/out bs=$((4096)) oflag=dsync
    3218+1 records in
    3218+1 records out
    13181130 bytes (13 MB) copied, 3.69961 s, 3.6 MB/s
    $ dd if=initrd.img-2.6.38-8-generic of=/tmp/out bs=$((4096 * 10)) oflag=dsync
    321+1 records in
    321+1 records out
    13181130 bytes (13 MB) copied, 0.471143 s, 28.0 MB/s
    
    Run Code Online (Sandbox Code Playgroud)

    这两个命令显示了一些缓冲的效果——第一个命令以 4096 字节块的形式写入数据,这可能是默认缓冲为您提供的。这大约比一次 16 个字节快 50 倍。第二条命令以 40960 字节块写入数据,速度仍然快了大约九倍。(总而言之,一次写入 40960 字节比一次写入 16 字节快大约 345 倍。)

    如果您的数据很小,这并不重要。毕竟,无论哪种方式都不会花费太多时间。如果您的数据很大,那么它可能更重要,具体取决于您一次写入的数据量以及它在底层设备的“字节边界”上排列的频率。

  2. 套接字上的某些协议可能会根据您发送数据的时间来改变其行为。如果您以增量方式构建数据,则可能会在单个数据包中发送部分数据,而基于数据包的接收器可能无法妥善处理此问题。(除了驱动某种游戏之外,我很难想象基于 TCP 的系统会出现此问题;基于 UDP 的系统更容易想象出现此问题。)