首页 > 解决方案 > 自 Python 2.7 以来,I/O 是否变慢了?

问题描述

我目前有一个小型项目,我想尽快在我的机器上对一个 20GB 的文件进行排序。这个想法是对文件进行分块,对块进行排序,然后合并这些块。我只是用不同的 Python 版本对 radixsort 代码进行计时,pyenv发现它2.7.183.6.103.7.7和. 谁能在这个简单的例子中解释为什么 Python 3.x 比 2.7.18 慢?是否添加了新功能?3.8.33.9.0a

import os


def chunk_data(filepath, prefixes):
    """
    Pre-sort and chunk the content of filepath according to the prefixes.

    Parameters
    ----------
    filepath : str
        Path to a text file which should get sorted. Each line contains
        a string which has at least 2 characters and the first two
        characters are guaranteed to be in prefixes
    prefixes : List[str]
    """
    prefix2file = {}
    for prefix in prefixes:
        chunk = os.path.abspath("radixsort_tmp/{:}.txt".format(prefix))
        prefix2file[prefix] = open(chunk, "w")

    # This is where most of the execution time is spent:
    with open(filepath) as fp:
        for line in fp:
            prefix2file[line[:2]].write(line)

执行时间(多次运行):

完整的代码在 Github 上,还有一个最小的完整版本

统一码

是的,我知道 Python 3 和 Python 2 处理字符串的方式不同。我尝试以二进制模式(rb/ wb)打开文件,请参阅“二进制模式”注释。在几次运行中,它们的速度要快一些。尽管如此,Python 2.7 在所有运行中都快得多。

尝试 1:字典访问

当我提出这个问题时,我认为字典访问可能是造成这种差异的一个原因。但是,我认为字典访问的总执行时间比 I/O 少得多。此外, timeit 没有显示任何重要的内容:

import timeit
import numpy as np

durations = timeit.repeat(
    'a["b"]',
    repeat=10 ** 6,
    number=1,
    setup="a = {'b': 3, 'c': 4, 'd': 5}"
)

mul = 10 ** -7

print(
    "mean = {:0.1f} * 10^-7, std={:0.1f} * 10^-7".format(
        np.mean(durations) / mul,
        np.std(durations) / mul
    )
)
print("min  = {:0.1f} * 10^-7".format(np.min(durations) / mul))
print("max  = {:0.1f} * 10^-7".format(np.max(durations) / mul))

尝试2:复制时间

作为一个简化的实验,我尝试复制 20GB 的文件:

Python 的东西是由以下代码生成的。

我的第一个想法是方差很大。所以这可能是原因。但是,chunk_data执行时间的方差也很高,但 Python 2.7 的平均值明显低于 Python 3.x。所以它似乎不像我在这里尝试的那样简单的 I/O 场景。

import time
import sys
import os


version = sys.version_info
version = "{}.{}.{}".format(version.major, version.minor, version.micro)


if os.path.isfile("numbers-tmp.txt"):
    os.remove("numers-tmp.txt")

t0 = time.time()
with open("numbers-large.txt") as fin, open("numers-tmp.txt", "w") as fout:
    for line in fin:
        fout.write(line)
t1 = time.time()


print("Python {}: {:0.0f}s".format(version, t1 - t0))

我的系统

标签: pythonpython-2.7performancepython-3.6python-3.8

解决方案


这是多种效果的组合,主要是 Python 3 在文本模式下工作时需要执行 unicode 解码/编码,如果在二进制模式下工作,它将通过专用缓冲 IO 实现发送数据。

首先,time.time用于测量执行时间使用的是墙时间,因此包括各种与 Python 无关的东西,例如操作系统级别的缓存和缓冲,以及存储介质的缓冲。它还反映了对需要存储介质的其他进程的任何干扰。这就是为什么您会看到时序结果出现这些巨大变化的原因。以下是我的系统的结果,每个版本连续运行七次:

py3 = [660.9, 659.9, 644.5, 639.5, 752.4, 648.7, 626.6]  # 661.79 +/- 38.58
py2 = [635.3, 623.4, 612.4, 589.6, 633.1, 613.7, 603.4]  # 615.84 +/- 15.09

尽管差异很大,但这些结果似乎确实表明了不同的时间安排,例如可以通过统计测试来证实:

>>> from scipy.stats import ttest_ind
>>> ttest_ind(p2, p3)[1]
0.018729004515179636

即只有 2% 的机会从相同的分布中出现时间。

我们可以通过测量过程时间而不是墙壁时间来获得更精确的图像。在 Python 2 中,这可以通过time.clockPython 3.3+ 提供time.process_time. 这两个函数报告以下时间:

py3_process_time = [224.4, 226.2, 224.0, 226.0, 226.2, 223.7, 223.8]  # 224.90 +/- 1.09
py2_process_time = [171.0, 171.1, 171.2, 171.3, 170.9, 171.2, 171.4]  # 171.16 +/- 0.16

现在数据中的分布要小得多,因为时间仅反映了 Python 进程。

该数据表明 Python 3 的执行时间要长约 53.7 秒。鉴于输入文件 ( 550_000_000) 中有大量行,每次迭代大约需要 97.7 纳秒。

导致执行时间增加的第一个影响是 Python 3 中的 unicode 字符串。二进制数据从文件中读取,解码,然后在写回时再次编码。在 Python 2 中,所有字符串都立即存储为二进制字符串,因此这不会引入任何编码/解码开销。您在测试中没有清楚地看到这种效果,因为它在各种外部资源引入的巨大变化中消失了,这些变化反映在墙上的时间差中。例如,我们可以测量从二进制到 unicode 到二进制的往返时间:

In [1]: %timeit b'000000000000000000000000000000000000'.decode().encode()                     
162 ns ± 2 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)

这确实包括两个属性查找以及两个函数调用,因此所需的实际时间小于上面报告的值。要查看对执行时间的影响,我们可以将测试脚本更改为使用二进制模式"rb""wb"而不是文本模式"r""w". 这减少了 Python 3 的计时结果,如下所示:

py3_binary_mode = [200.6, 203.0, 207.2]  # 203.60 +/- 2.73

这将每次迭代的处理时间减少了大约 21.3 秒或 38.7 纳秒。这与往返基准的计时结果减去名称查找和函数调用的计时结果一致:

In [2]: class C: 
   ...:     def f(self): pass 
   ...:                                                                                       

In [3]: x = C()                                                                               

In [4]: %timeit x.f()                                                                         
82.2 ns ± 0.882 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)

In [5]: %timeit x                                                                             
17.8 ns ± 0.0564 ns per loop (mean ± std. dev. of 7 runs, 100000000 loops each)

这里%timeit x测量解析全局名称的额外开销,x因此属性查找和函数调用使82.2 - 17.8 == 64.4秒数。从上述往返数据中减去此开销两次可以得到162 - 2*64.4 == 33.2秒数。

现在,使用二进制模式的 Python 3 和 Python 2 之间仍然存在 32.4 秒的差异。这是因为 Python 3 中的所有 IO 都经历了(相当复杂的)实现,而在 Python 2 中,该方法进行得相当简单。io.BufferedWriter .writefile.writefwrite

我们可以在两种实现中检查文件对象的类型:

$ python3.8
>>> type(open('/tmp/test', 'wb'))
<class '_io.BufferedWriter'>

$ python2.7
>>> type(open('/tmp/test', 'wb'))
<type 'file'>

这里我们还需要注意的是,上述 Python 2 的计时结果是使用文本模式获得的,而不是二进制模式。二进制模式旨在支持所有实现缓冲区 协议的对象,这会导致对字符串也执行额外的工作(另请参阅此问题)。如果我们也为 Python 2 切换到二进制模式,那么我们将获得:

py2_binary_mode = [212.9, 213.9, 214.3]  # 213.70 +/- 0.59

这实际上比 Python 3 的结果(18.4 ns / 迭代)大一点。

这两种实现方式在其他细节上也有所不同,例如dict实现方式。为了测量这种效果,我们可以创建一个相应的设置:

from __future__ import print_function

import timeit

N = 10**6
R = 7
results = timeit.repeat(
    "d[b'10'].write",
    setup="d = dict.fromkeys((str(i).encode() for i in range(10, 100)), open('test', 'rb'))",  # requires file 'test' to exist
    repeat=R, number=N
)
results = [x/N for x in results]
print(['{:.3e}'.format(x) for x in results])
print(sum(results) / R)

这给出了 Python 2 和 Python 3 的以下结果:

  • Python 2:~ 56.9 纳秒
  • Python 3:~ 78.1 纳秒

对于完整的 550M 迭代,大约 21.2 纳秒的额外差异相当于大约 12 秒。

上面的时序代码只检查 dict 查找是否有一个键,所以我们还需要验证没有哈希冲突:

$ python3.8 -c "print(len({str(i).encode() for i in range(10, 100)}))"
90
$ python2.7 -c "print len({str(i).encode() for i in range(10, 100)})"
90

推荐阅读