为什么打印到标准输出这么慢？可以提速吗？

Question

我一直对使用 print 语句简单地输出到终端需要多长时间感到惊讶/沮丧。在最近一些令人痛苦的缓慢记录之后，我决定研究它，并惊讶地发现几乎所有所花费的时间都在等待终端处理结果。

可以以某种方式加快写入标准输出的速度吗？

我写了一个脚本（这个问题底部的'print_timer.py'）来比较将 100k 行写入标准输出、文件以及将标准输出重定向到/dev/null 时的时间。以下是计时结果：

$ python print_timer.py
this is a test
this is a test
<snipped 99997 lines>
this is a test
-----
timing summary (100k lines each)
-----
print                         :11.950 s
write to file (+ fsync)       : 0.122 s
print with stdout = /dev/null : 0.050 s

哇。为了确保 python 没有在幕后做一些事情，比如认识到我将 stdout 重新分配给 /dev/null 之类的，我在脚本之外进行了重定向......

$ python print_timer.py > /dev/null
-----
timing summary (100k lines each)
-----
print                         : 0.053 s
write to file (+fsync)        : 0.108 s
print with stdout = /dev/null : 0.045 s

所以这不是 python 技巧，它只是终端。我一直都知道将输出转储到 /dev/null 会加快速度，但从未想过它有那么重要！

tty 的速度让我吃惊。为什么写入物理磁盘比写入“屏幕”（可能是全 RAM 操作）快得多，并且实际上与使用 /dev/null 转储到垃圾中一样快？

This link 谈论终端将如何阻止 I/O，以便它可以“解析 [输入]、更新其帧缓冲区、与 X 服务器通信以滚动窗口等等” ...但我不完全明白。什么可以花这么长时间？

我预计没有出路（缺少更快的 tty 实现？）但我还是会问。

---

更新：在阅读了一些 cmets 之后，我想知道我的屏幕尺寸实际上对打印时间有多大影响，而且它确实具有一定的意义。上面真正慢的数字是我的 Gnome 终端被炸到 1920x1200。如果我把它减小得非常小，我会得到......

-----
timing summary (100k lines each)
-----
print                         : 2.920 s
write to file (+fsync)        : 0.121 s
print with stdout = /dev/null : 0.048 s

这当然更好（~4x），但不会改变我的问题。它只是添加到我的问题，因为我不明白为什么终端屏幕渲染应该减慢应用程序写入标准输出的速度。为什么我的程序需要等待屏幕渲染才能继续？

不是所有终端/tty 应用程序都是平等的吗？我还没有做实验。在我看来，终端应该能够缓冲所有传入的数据，不可见地解析/渲染它，并且仅以合理的帧速率渲染当前屏幕配置中可见的最新块。因此，如果我可以在大约 0.1 秒内将 +fsync 写入磁盘，那么终端应该能够以该顺序完成相同的操作（在执行此操作时可能会进行一些屏幕更新）。

我仍然有点希望有一个可以从应用程序端更改的 tty 设置，以使这种行为对程序员更好。如果这严格来说是一个终端应用程序问题，那么这可能甚至不属于 StackOverflow？

我错过了什么？

---

这是用于生成计时的python程序：

import time, sys, tty
import os

lineCount = 100000
line = "this is a test"
summary = ""

cmd = "print"
startTime_s = time.time()
for x in range(lineCount):
    print line
t = time.time() - startTime_s
summary += "%-30s:%6.3f s\n" % (cmd, t)

#Add a newline to match line outputs above...
line += "\n"

cmd = "write to file (+fsync)"
fp = file("out.txt", "w")
startTime_s = time.time()
for x in range(lineCount):
    fp.write(line)
os.fsync(fp.fileno())
t = time.time() - startTime_s
summary += "%-30s:%6.3f s\n" % (cmd, t)

cmd = "print with stdout = /dev/null"
sys.stdout = file(os.devnull, "w")
startTime_s = time.time()
for x in range(lineCount):
    fp.write(line)
t = time.time() - startTime_s
summary += "%-30s:%6.3f s\n" % (cmd, t)

print >> sys.stderr, "-----"
print >> sys.stderr, "timing summary (100k lines each)"
print >> sys.stderr, "-----"
print >> sys.stderr, summary

Answer 1

为什么写入物理磁盘比写入“屏幕”（可能是全 RAM 操作）要快得多，并且实际上与使用 /dev/null 转储到垃圾中一样快？

恭喜，您刚刚发现了 I/O 缓冲的重要性。 :-)

磁盘似乎更快，因为它是高度缓冲的：所有 Python 的 write() 调用都在实际写入物理磁盘之前返回。 （操作系统稍后会这样做，将数千个单独的写入组合成一个大而高效的块。）

另一方面，终端很少或根本不做缓冲：每个人 print / write(line) 等待完整写入（即显示到输出设备）完成。

为了使比较公平，您必须使文件 test 使用与终端相同的输出缓冲，您可以通过将示例修改为：

fp = file("out.txt", "w", 1)   # line-buffered, like stdout
[...]
for x in range(lineCount):
    fp.write(line)
    os.fsync(fp.fileno())      # wait for the write to actually complete

我在我的机器上运行了你的文件写入测试，通过缓冲，这里也是 0.05 秒，100,000 行。

但是，通过以上对无缓冲写入的修改，仅将 1,000 行写入磁盘需要 40 秒。我放弃了等待 100,000 行来写，但从前面推断，这将需要 一个多小时。

这让终端机的 11 秒变得清晰起来，不是吗？

因此，要回答您最初的问题，考虑到所有因素，写入终端实际上​​非常快，并且没有太多空间可以让它更快（但各个终端的工作量确实有所不同；请参阅 Russ 的对此答案发表评论）。

（您可以添加更多的写入缓冲，例如使用磁盘 I/O，但是在刷新缓冲区之前您不会看到写入终端的内容。这是一种权衡：交互性与批量效率。）

Answer 2

感谢所有cmets！在您的帮助下，我最终自己回答了这个问题。不过，回答自己的问题感觉很脏。

问题 1：为什么打印到标准输出很慢？

答案：打印到标准输出并不本身就很慢。您使用的终端很慢。它与应用程序端的 I/O 缓冲几乎为零（例如：python 文件缓冲）。见下文。

问题 2：可以提速吗？

答案：可以，但似乎不是从程序方面（对标准输出进行“打印”的一方）。要加快速度，请使用更快的不同终端仿真器。

解释...

我尝试了一个名为wterm 的自称为“轻量级”终端程序，并获得了显着更好的结果。下面是我的测试脚本的输出（在问题的底部），在 wterm 以 1920x1200 在同一系统上运行时，基本打印选项使用 gnome-terminal 需要 12 秒：

----- 时序摘要（每个 100k 行） ----- 打印：0.261 秒 写入文件 (+fsync) : 0.110 s 使用 stdout = /dev/null 打印：0.050 秒

0.26s 比 12s 好很多！我不知道wterm 是否更智能地按照我的建议（以合理的帧速率渲染“可见”尾部）来渲染屏幕，或者它是否比@“做得更少” 987654325@。不过，就我的问题而言，我已经得到了答案。 gnome-terminal 很慢。

所以 - 如果您有一个长时间运行的脚本，您觉得它很慢并且它会向标准输出发送大量文本...尝试不同的终端，看看它是否更好！

请注意，我几乎从 ubuntu/debian 存储库中随机提取了 wterm。 This link 可能是同一个终端，但我不确定。我没有测试任何其他终端模拟器。

---

更新：因为我不得不抓痒，我用相同的脚本和全屏 (1920x1200) 测试了一大堆其他终端模拟器。我手动收集的统计数据在这里：

wterm 0.3s aterm 0.3s rxvt 0.3s mrxvt 0.4s 控制台0.6s yakuake 0.7s lxterminal 7s xterm 9s gnome 终端 12s xfce4-终端 12s vala-terminal 18s xvt 48s

记录的时间是手动收集的，但它们非常一致。我记录了最好的（ish）价值。显然是 YMMV。

作为奖励，这是对一些可用的各种终端仿真器的有趣之旅！我很惊讶我的第一个“替代”测试竟然是最好的。

Answer 3

除了输出可能默认为行缓冲模式外，输出到终端还会导致您的数据流入具有最大吞吐量的终端和串行线路，或伪终端和单独的进程，即处理显示事件循环，从某种字体渲染字符，移动显示位以实现滚动显示。后一种情况可能分布在多个进程上（例如 telnet 服务器/客户端、终端应用程序、X11 显示服务器），因此也存在上下文切换和延迟问题。

Answer 4

您的重定向可能没有任何作用，因为程序可以确定它们的输出 FD 是否指向 tty。

当指向终端时，stdout 很可能是行缓冲的（与 C 的 stdout 流行为相同）。

作为一个有趣的实验，尝试将输出传送到cat。

---

我尝试了自己的有趣实验，结果如下。

$ python test.py 2>foo
...
$ cat foo
-----
timing summary (100k lines each)
-----
print                         : 6.040 s
write to file                 : 0.122 s
print with stdout = /dev/null : 0.121 s

$ python test.py 2>foo |cat
...
$ cat foo
-----
timing summary (100k lines each)
-----
print                         : 1.024 s
write to file                 : 0.131 s
print with stdout = /dev/null : 0.122 s

Answer 5

我不能谈论技术细节，因为我不了解它们，但这并不让我感到惊讶：终端不是为打印大量这样的数据而设计的。事实上，您甚至提供了一个指向大量 GUI 内容的链接，每次您想要打印某些东西时它都必须这样做！请注意，如果您改为使用pythonw 调用脚本，则不需要15 秒；这完全是一个 GUI 问题。将stdout 重定向到一个文件以避免这种情况：

import contextlib, io
@contextlib.contextmanager
def redirect_stdout(stream):
    import sys
    sys.stdout = stream
    yield
    sys.stdout = sys.__stdout__

output = io.StringIO
with redirect_stdout(output):
    ...

Answer 6

打印到终端会很慢。不幸的是，没有编写一个新的终端实现，我真的看不出你会如何显着加快速度。