为什么StringIO对象比实际文件对象慢？

Question

我期待通过StringIO那里说的来源说一些注意事项：

1. 使用真正的文件往往是速度更快（但不太方便）。
2. C中还有一个更快的实现，名为cStringIO，但它不是可以子类化的。

StringIO就像一个内存文件对象， 为什么它不是真正的文件对象慢？

Answer 1

Python的文件处理is implemented entirely in C。这意味着它非常快速（至少与本机C代码的数量级相同）。

但是，StringIO库是用Python编写的。模块本身因此被解释，并伴随着相关的性能损失。

如您所知，还有另一个模块cStringIO，其中包含一个similar interface，您可以在性能敏感的代码中使用该模块。 的原因，这是不是子类化是因为它是用C写的

Answer 2

从源代码并不是很明显，但是python文件对象是直接构建在C库函数上的，可能有一小部分python呈现一个python类，甚至是一个C wrapper来呈现一个python类。本地C库将被高度优化以从磁盘读取字节和块。 python的StringIO库都是原生的python代码 - 比原生C代码慢。

Answer 3

这是不实际上对Python的解释性质：BytesIO是在Python *实现相同StringIO，但仍击败文件I/O 。

实际上，StringIO比StringIO的理想用例（一次写入空缓冲区开始处）下的文件I/O更快。事实上，如果写入足够大，它甚至会打败cStringIO。看到我的问题here。

那么为什么StringIO被认为是“慢”？ StringIO的真正问题得到不可变序列的支持，无论是str还是unicode。这很好，如果你只写一次，显然。但是，正如我的问题tdelaney's answer所指出的那样，当写入随机位置时，它会减慢一吨（如10-100倍），因为每次它在中间写入时都必须复制整个支持序列。

BytesIO没有这个问题，因为它支持一个（可变的）bytearray来代替。同样，不管cStringIO做什么，它似乎更容易处理随机写入。我猜想它在内部打破了不变性规则，因为C字符串是可变的。

*好吧，无论如何_pyio的版本。 io的标准库版本是用C编写的。