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

Question

我正在查看StringIO它所说的一些注释的来源：

1. 使用真实文件通常更快（但不太方便）。
2. 在 C 中还有一个更快的实现，称为cStringIO，但它不是可子类化的。

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

Answer 1

这实际上与 Python 的解释性质无关BytesIO：在 Python* 中实现，与 相同StringIO，但仍优于文件 I/O。

实际上，在的理想用例下（单次写入空缓冲区的开头）StringIO比文件 I/O 更快。StringIO实际上，如果写入足够大，它甚至会击败cStringIO. 在这里查看我的问题。

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

BytesIO没有这个问题，因为它是由 (mutable) 支持的bytearray。同样，无论做什么cStringIO，它似乎更容易处理随机写入。我猜它在内部打破了不变性规则，因为 C 字符串是可变的。

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

Answer 2

Python 的文件处理完全在 C 中实现。这意味着它非常快（至少与本机 C 代码处于同一数量级）。

然而，StringIO 库是用 Python 编写的。因此，模块本身会被解释，并带有相关的性能损失。

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

Answer 3

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