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

我正在查看

StringIO

的源代码，其中有一些注释：

使用真实文件通常更快（但不太方便）

在C中还有一个更快的实现，叫做

cStringIO

，但是 它不是子类

StringIO

就像一个内存文件对象，

---

为什么它比真正的文件对象慢？

从源代码上看不一定很明显，但是python文件对象是直接构建在C库函数上的，很可能是一小层python来表示python类，甚至是一个C包装器来表示python类。本机C库将进行高度优化，以从磁盘读取字节和块。python StringIO库都是本机python代码，比本机C代码慢。

python的文件处理。这意味着它相当快（至少与本机C代码的数量级相同）

然而，StringIO库是用Python编写的。因此，将解释模块本身，以及相关的性能惩罚

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

这实际上与Python的解释性质无关：

BytesIO

是用Python*实现的，与

StringIO

相同，但仍然优于文件I/O

事实上，

StringIO

比

StringIO

的理想用例（对空缓冲区开头的一次写入）下的文件I/O更快。实际上，如果写操作足够大，它甚至会超过cStringIO。见我的问题

那么为什么

StringIO

被认为是“慢”呢

StringIO

的真正问题在于不可变序列的支持，无论是

str

还是

unicode

。很明显，如果你只写一次就可以了。但是，正如我的问题所指出的，当写入随机位置时，它会减慢一吨（例如，10-100x），因为每次在中间写入时，它必须复制整个支持序列。

BytesIO

没有这个问题，因为它是由（可变的）

bytearray

支持的。同样，无论cStringIO做什么，它似乎都能更轻松地处理随机写入。我猜它在内部打破了不变性规则，因为C字符串是可变的

---

*无论如何，

\u pyio

中的版本是。

io

中的标准库版本是用C编写的。

ok-重新阅读这个问题，它是矛盾的。需要一个小的编辑-完成：-）对不起，我的英语很差，我的意思是

查找

，而不是

查找

。谢谢你的回答。@sapi-BytesIO有类似的东西吗？回答得好，竖起大拇指！