Python慢读性能问题答案

【问题标题】：Python slow read performance issuePython慢读性能问题
【发布时间】：2014-11-28 11:00:02
【问题描述】：

在之前的一个线程之后，我将问题归结为基本问题，在从 Perl 脚本迁移到 Python 脚本时，我发现在 Python 中使用 slurping 文件存在巨大的性能问题。在 Ubuntu 服务器上运行它。

注意：这不是 X 与 Y 的话题，我需要从根本上知道是这样还是我在做一些愚蠢的事情。

我创建了我的测试数据，50,000 个 10kb 文件（这反映了我正在处理的平均文件大小）：

mkdir 1
cd 1
for i in {1..50000}; do dd if=/dev/zero of=$i.xml bs=1 count=10000; done
cd ..
cp -r 1 2

尽可能简单地创建了我的 2 个脚本：

Perl

foreach my $file (<$ARGV[0]/*.xml>){
    my $fh;
    open($fh, "< $file");
    my $contents = do { local $/; <$fh> };
    close($fh);
}

Python

import glob, sys
for file in glob.iglob(sys.argv[1] + '/*.xml'):
    with open(file) as x:
        f = x.read()

然后我清除了缓存并运行了我的 2 个 slurp 脚本，在每次运行之间我再次使用以下命令清除了缓存：

sync; sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

然后进行监控以确保它每次都从磁盘读取所有内容：

sudo iotop -a -u me

我在具有 RAID 10 磁盘的物理机器和我设置的全新 VM 上尝试了此操作，其中 VM 位于 RAID 1 SSD 上，刚刚包括从我的 VM 运行的测试，因为物理服务器几乎相同，只是速度更快.

$ time python readFiles.py 1
    real    5m2.493s
    user    0m1.783s
    sys     0m5.013s

$ time perl readFiles.pl 2
    real    0m13.059s
    user    0m1.690s
    sys     0m2.471s

$ time perl readFiles.pl 2
    real    0m13.313s
    user    0m1.670s
    sys     0m2.579s

$ time python readFiles.py 1
    real    4m43.378s
    user    0m1.772s
    sys     0m4.731s

我在 iotop 上注意到，当 Perl 运行 DISK READ 时大约 45 M/s 和 IOWAIT 大约 70%，当运行 Python 时 DISK READ 是 2M/s 和 IOWAIT 97%。将它们归结为尽可能简单，我不确定从这里到哪里去。

如果相关

$ python
Python 2.7.6 (default, Mar 22 2014, 22:59:56)
[GCC 4.8.2] on linux2

$ perl -v
This is perl 5, version 18, subversion 2 (v5.18.2) built for x86_64-linux-gnu-thread-multi

应要求提供更多信息

我运行 strace 并获取了文件 1000.xml 的信息，但似乎都在做同样的事情：

Perl

$strace -f -T -o trace.perl.1 perl readFiles.pl 2

32303 open("2/1000.xml", O_RDONLY)      = 3 <0.000020>
32303 ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 0x7fff7f6f7b90) = -1 ENOTTY (Inappropriate ioctl for device) <0.000016>
32303 lseek(3, 0, SEEK_CUR)             = 0 <0.000016>
32303 fstat(3, {st_mode=S_IFREG|0664, st_size=10000, ...}) = 0 <0.000016>
32303 fcntl(3, F_SETFD, FD_CLOEXEC)     = 0 <0.000017>
32303 fstat(3, {st_mode=S_IFREG|0664, st_size=10000, ...}) = 0 <0.000030>
32303 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8192) = 8192 <0.005323>
32303 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8192) = 1808 <0.000022>
32303 read(3, "", 8192)                 = 0 <0.000019>
32303 close(3)                          = 0 <0.000017>

Python

$strace -f -T -o trace.python.1 python readFiles.py 1

32313 open("1/1000.xml", O_RDONLY)      = 3 <0.000021>
32313 fstat(3, {st_mode=S_IFREG|0664, st_size=10000, ...}) = 0 <0.000017>
32313 fstat(3, {st_mode=S_IFREG|0664, st_size=10000, ...}) = 0 <0.000019>
32313 lseek(3, 0, SEEK_CUR)             = 0 <0.000018>
32313 fstat(3, {st_mode=S_IFREG|0664, st_size=10000, ...}) = 0 <0.000018>
32313 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa18820a000 <0.000019>
32313 lseek(3, 0, SEEK_CUR)             = 0 <0.000018>
32313 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8192) = 8192 <0.006795>
32313 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 1808 <0.000031>
32313 read(3, "", 4096)                 = 0 <0.000018>
32313 close(3)                          = 0 <0.000027>
32313 munmap(0x7fa18820a000, 4096)      = 0 <0.000022>

我注意到但不确定是否相关的一个区别是，Perl 似乎在开始打开所有文件之前对所有文件运行此命令，而 python 没有：

32303 lstat("2/1000.xml", {st_mode=S_IFREG|0664, st_size=10000, ...}) = 0 <0.000022>

还使用 -c 运行 strace（只接了前几个调用）：

Perl

$ time strace -f -c perl readFiles.pl 2
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 44.07    3.501471          23    150018           read
 12.54    0.996490          10    100011           fstat
  9.47    0.752552          15     50000           lstat
  7.99    0.634904          13     50016           open
  6.89    0.547016          11     50017           close
  6.19    0.491944          10     50008     50005 ioctl
  6.12    0.486208          10     50014         3 lseek
  6.10    0.484374          10     50001           fcntl

real    0m37.829s
user    0m6.373s
sys     0m25.042s

Python

$ time strace -f -c python readFiles.py 1
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 42.97    4.186173          28    150104           read
 15.58    1.518304          10    150103           fstat
 10.51    1.023681          20     50242       174 open
 10.12    0.986350          10    100003           lseek
  7.69    0.749387          15     50047           munmap
  6.85    0.667576          13     50071           close
  5.90    0.574888          11     50073           mmap

real    5m5.237s
user    0m7.278s
sys     0m30.736s

是否在打开 -T 的情况下对 strace 输出进行了一些解析，并计算了每个文件的前 8192 字节读取，很明显这是时间的去向，下面是文件第一次读取 50000 所花费的总时间其次是每次读取的平均时间。

300.247128000002 (0.00600446220302379)   - Python
11.6845620000003 (0.000233681892724297)  - Perl

不确定这是否有帮助！

更新 2 更新了 Python 中的代码以使用 os.open 和 os.read 并只读取前 4096 个字节（这对我有用，因为我想要的信息位于文件的顶部），还消除了 strace 中的所有其他调用：

18346 open("1/1000.xml", O_RDONLY)      = 3 <0.000026>
18346 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096 <0.007206>
18346 close(3)                          = 0 <0.000024>

$ time strace -f -c python readFiles.py 1
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 55.39    2.388932          48     50104           read
 22.86    0.986096          20     50242       174 open
 20.72    0.893579          18     50071           close

real    4m48.751s
user    0m3.078s
sys     0m12.360s

Total Time (avg read call)
282.28626 (0.00564290374812595)

仍然没有更好...接下来我将在 Azure 上创建一个 VM 并尝试另一个示例！

更新 3 - 抱歉这么大！！

好的，在 3 个设置上使用您的 (@J.F.Sebastian) 脚本获得了一些有趣的结果，为简洁起见，在开始时剥离了输出，还删除了所有从缓存中快速运行的测试，如下所示：

0.23user 0.26system 0:00.50elapsed 99%CPU (0avgtext+0avgdata 9140maxresident)k
0inputs+0outputs (0major+2479minor)pagefaults 0swaps

Azure A2 标准 VM（2 核 3.5GB RAM 磁盘未知但速度慢）

$ uname -a
Linux servername 3.13.0-35-generic #62-Ubuntu SMP Fri Aug 15 01:58:42 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
$ python
Python 2.7.6 (default, Mar 22 2014, 22:59:56)
[GCC 4.8.2] on linux2
$ perl -v
This is perl 5, version 18, subversion 2 (v5.18.2) built for x86_64-linux-gnu-thread-multi
(with 41 registered patches, see perl -V for more detail)

+ /usr/bin/time perl slurp.pl 1
1.81user 2.95system 3:11.28elapsed 2%CPU (0avgtext+0avgdata 9144maxresident)k
1233840inputs+0outputs (20major+2461minor)pagefaults 0swaps
+ clearcache
+ sync
+ sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
+ /usr/bin/time python slurp.py 1
1.56user 3.76system 3:06.05elapsed 2%CPU (0avgtext+0avgdata 8024maxresident)k
1232232inputs+0outputs (14major+52273minor)pagefaults 0swaps
+ /usr/bin/time perl slurp.pl 2
1.90user 3.11system 6:02.17elapsed 1%CPU (0avgtext+0avgdata 9144maxresident)k
1233776inputs+0outputs (16major+2465minor)pagefaults 0swaps

两者的第一次 slurp 结果相当，不确定在第二次 Perl slurp 期间发生了什么？

我的 VMWare Linux VM（2 核 8GB RAM 磁盘 RAID1 SSD）

$ uname -a
Linux servername 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
$ python
Python 2.7.6 (default, Mar 22 2014, 22:59:56)
[GCC 4.8.2] on linux2
$ perl -v
This is perl 5, version 18, subversion 2 (v5.18.2) built for x86_64-linux-gnu-thread-multi
(with 41 registered patches, see perl -V for more detail)

+ /usr/bin/time perl slurp.pl 1
1.66user 2.55system 0:13.28elapsed 31%CPU (0avgtext+0avgdata 9136maxresident)k
1233152inputs+0outputs (20major+2460minor)pagefaults 0swaps
+ clearcache
+ sync
+ sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
+ /usr/bin/time python slurp.py 1
2.10user 4.67system 4:45.65elapsed 2%CPU (0avgtext+0avgdata 8012maxresident)k
1232056inputs+0outputs (14major+52269minor)pagefaults 0swaps
+ /usr/bin/time perl slurp.pl 2
2.13user 4.11system 5:01.40elapsed 2%CPU (0avgtext+0avgdata 9140maxresident)k
1233264inputs+0outputs (16major+2463minor)pagefaults 0swaps

这一次，和以前一样，Perl 在第一次 slurp 上要快得多，不确定在第二次 Perl slurp 上会发生什么，尽管以前没有见过这种行为。再次运行 measure.sh ，结果完全相同，需要几秒钟。然后我做了任何普通人都会做的事情，更新内核以匹配 Azure 机器 3.13.0-35-generic 并再次运行 measure.sh 并且对结果没有任何影响。

出于好奇，我随后交换了 measure.sh 中的 1 和 2 参数，发生了一些奇怪的事情。Perl 变慢了，Python 变快了！

+ /usr/bin/time perl slurp.pl 2
1.78user 3.46system 4:43.90elapsed 1%CPU (0avgtext+0avgdata 9140maxresident)k
1234952inputs+0outputs (21major+2458minor)pagefaults 0swaps
+ clearcache
+ sync
+ sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
+ /usr/bin/time python slurp.py 2
1.19user 3.09system 0:10.67elapsed 40%CPU (0avgtext+0avgdata 8012maxresident)k
1233632inputs+0outputs (14major+52269minor)pagefaults 0swaps
+ /usr/bin/time perl slurp.pl 1
1.36user 2.32system 0:13.40elapsed 27%CPU (0avgtext+0avgdata 9136maxresident)k
1232032inputs+0outputs (17major+2465minor)pagefaults 0swaps

这让我更加困惑:-(

物理服务器（32 核 132 GB RAM 磁盘 RAID10 SAS）

$ uname -a
Linux servername 3.5.0-23-generic #35~precise1-Ubuntu SMP Fri Jan 25 17:13:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
$ python
Python 2.7.3 (default, Aug  1 2012, 05:14:39)
[GCC 4.6.3] on linux2
$ perl -v
This is perl 5, version 14, subversion 2 (v5.14.2) built for x86_64-linux-gnu-thread-multi
(with 55 registered patches, see perl -V for more detail)

+ /usr/bin/time perl slurp.pl 1
2.22user 2.60system 0:15.78elapsed 30%CPU (0avgtext+0avgdata 43728maxresident)k
1233264inputs+0outputs (15major+2984minor)pagefaults 0swaps
+ clearcache
+ sync
+ sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
+ /usr/bin/time python slurp.py 1
2.51user 4.79system 1:58.53elapsed 6%CPU (0avgtext+0avgdata 34256maxresident)k
1234752inputs+0outputs (16major+52385minor)pagefaults 0swaps
+ /usr/bin/time perl slurp.pl 2
2.17user 2.95system 0:06.96elapsed 73%CPU (0avgtext+0avgdata 43744maxresident)k
1232008inputs+0outputs (14major+2987minor)pagefaults 0swaps

Perl 似乎每次都赢了。

困惑

考虑到我的本地虚拟机的奇怪之处，当我交换目录时，这是我最能控制的机器，我将尝试使用二进制方法来运行 python 与 perl 的所有可能选项，使用 1 或 2 作为数据目录并尝试多次运行它们以保持一致性，但这需要一段时间，而且我有点疯狂，所以可能需要先中断！我想要的只是一致性:-(

更新 4 - 一致性

（以下是在 ubuntu-14.04.1-server 虚拟机上运行，内核为 3.13.0-35-generic #62-Ubuntu）

我想我已经找到了一些一致性，在 data dir 1/2 上运行 Python/Perl slurp 的各种可能的测试我发现了以下内容：

Python 在创建文件（即由 dd 创建）时总是很慢
Python 在复制文件（即由 cp -r 创建）上总是很快
Perl 在创建文件（即由 dd 创建）上总是很快
Perl 在复制文件时总是很慢（即由 cp -r 创建）

所以我查看了操作系统级别的复制，似乎在 Ubuntu 上，“cp”的行为方式与 Python 相同，即原始文件速度慢而复制文件速度快。

这是我运行的结果，我在具有单个 SATA HD 和 RAID10 系统的机器上做了几次，结果：

$ mkdir 1
$ cd 1
$ for i in {1..50000}; do dd if=/dev/urandom of=$i.xml bs=1K count=10; done
$ cd ..
$ cp -r 1 2
$ sync; sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
$ time strace -f -c -o trace.copy2c cp -r 2 2copy
    real    0m28.624s
    user    0m1.429s
    sys     0m27.558s
$ sync; sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
$ time strace -f -c -o trace.copy1c cp -r 1 1copy
    real    5m21.166s
    user    0m1.348s
    sys     0m30.717s

跟踪结果显示时间花费在哪里

$ head trace.copy1c trace.copy2c
==> trace.copy1c <==
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 60.09    2.541250          25    100008           read
 12.22    0.516799          10     50000           write
  9.62    0.406904           4    100009           open
  5.59    0.236274           2    100013           close
  4.80    0.203114           4     50004         1 lstat
  4.71    0.199211           2    100009           fstat
  2.19    0.092662           2     50000           fadvise64
  0.72    0.030418         608        50           getdents
==> trace.copy2c <==
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 47.86    0.802376           8    100008           read
 13.55    0.227108           5     50000           write
 13.02    0.218312           2    100009           open
  7.36    0.123364           1    100013           close
  6.83    0.114589           1    100009           fstat
  6.31    0.105742           2     50004         1 lstat
  3.38    0.056634           1     50000           fadvise64
  1.62    0.027191         544        50           getdents

所以复制副本似乎比复制原始文件快得多，我目前的猜测是，当复制文件时，文件在磁盘上的对齐比最初创建时更好，从而使它们更有效地读取？

有趣的是，'rsyn' 和 'cp' 似乎以相反的方式快速工作，很像 Perl 和 Python！

$ rm -rf 1copy 2copy; sync; sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'; echo "Rsync 1"; /usr/bin/time rsync -a 1 1copy; sync; sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'; echo "Rsync 2"; /usr/bin/time rsync -a 2 2copy
Rsync 1
    3.62user 3.76system 0:13.00elapsed 56%CPU (0avgtext+0avgdata 5072maxresident)k
    1230600inputs+1200000outputs (13major+2684minor)pagefaults 0swaps
Rsync 2
    4.87user 6.52system 5:06.24elapsed 3%CPU (0avgtext+0avgdata 5076maxresident)k
    1231832inputs+1200000outputs (13major+2689minor)pagefaults 0swaps

$ rm -rf 1copy 2copy; sync; sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'; echo "Copy 1"; /usr/bin/time cp -r 1 1copy; sync; sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'; echo "Copy 2"; /usr/bin/time cp -r 2 2copy
Copy 1
    0.48user 6.42system 5:05.30elapsed 2%CPU (0avgtext+0avgdata 1212maxresident)k
    1229432inputs+1200000outputs (6major+415minor)pagefaults 0swaps
Copy 2
    0.33user 4.17system 0:11.13elapsed 40%CPU (0avgtext+0avgdata 1212maxresident)k
    1230416inputs+1200000outputs (6major+414minor)pagefaults 0swaps

【问题讨论】：

似乎不是受 CPU 限制的问题。你能strace 比较一下他们是如何读取文件的吗？
我在我的 SSD 上运行了这些，Perl、CPython 2 和 PyPy 的时间分别为 4.7 秒、8.8 秒和 8.2 秒。你可以试试 PyPy 看看它是否是一个实现错误吗？
@Veedrac 安装了 PyPy（带有 GCC 4.8.2 的 PyPy 2.2.1）并再次运行 python 脚本，但对于随机 50000 个 10kb 文件，Perl 的 5m7s 与 38s 没有真正的区别
@Puciek 有证据表明 Python、Perl 和 Ubuntu 在不同硬件平台上的组合会发生一些奇怪的事情，这使得它不仅仅是一个 Python 错误？就 Perl 或 Python 中的代码而言，我显然没有做任何愚蠢的事情，但也许有一些与 Ubuntu 甚至可能导致此问题的磁盘配置相关的低级事情，到目前为止，这里的帮助非常有用试图缩小问题的范围。如果我找到了答案，我想它会在这里对未来的人有所帮助。
我也想知道 glob.glob 和 glob.iglob 在这个测量中的比较。

标签： python performance perl io

【解决方案1】：

我将只关注你的一个例子，因为其余的事情应该是类比的：

我认为，在这种情况下可能重要的是预读（或可能与此相关的另一种技术）功能：

让我们考虑这样的例子：

正如您通过 dd 命令所做的那样，我在“1”目录（名称 1.xml 到 1000.xml）中创建了 1000 个 xml 文件，然后我将原始目录 1 复制到目录 2

$ mkdir 1
$ cd 1
$ for i in {1..1000}; do dd if=/dev/urandom of=$i.xml bs=1K count=10; done
$ cd ..
$ cp -r 1 2
$ sync; sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
$ time strace -f -c -o trace.copy2c cp -r 2 2copy
$ sync; sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
$ time strace -f -c -o trace.copy1c cp -r 1 1copy

在下一步中，我调试了 cp 命令（通过 strace），以了解复制数据的顺序：

所以 cp 按以下顺序执行（仅前 4 个文件，因为我看到第二次从原始目录读取比从复制目录第二次读取更耗时）

100.xml 150.xml 58.xml 64.xml ... * 在我的例子中

现在，看看这些文件使用的文件系统块（debugfs 输出 - ext3 fs）：

原目录：

BLOCKS:
(0-9):63038-63047 100.xml
(0-9):64091-64100 150.xml
(0-9):57926-57935 58.xml
(0-9):60959-60968 64.xml
....


Copied directory:
BLOCKS:
(0-9):65791-65800 100.xml
(0-9):65801-65810 150.xml
(0-9):65811-65820 58.xml
(0-9):65821-65830 64.xml

....

如您所见，在“复制目录”中，块是相邻的，因此这意味着在读取第一个文件 100.xml 期间，“预读” 技术（控制器或系统设置）可以提高性能。

dd 以 1.xml 到 1000.xml 的顺序创建文件，但 cp 命令以另一个顺序（100.xml、150.xml、58.xml、64.xml）复制它。所以当你执行时：

cp -r 1 1copy

要将此目录复制到另一个目录，您复制的文件块不相邻，因此读取此类文件需要更多时间。

当你复制你通过cp命令复制的dir时（所以文件不是由dd命令创建的），那么文件是相邻的所以创建：

cp -r 2 2copy

复制副本速度更快。

总结：因此，要测试 python/perl 的性能，您应该使用相同的目录（或 cp 命令复制的两个目录），还可以使用选项 O_DIRECT 来读取绕过所有内核缓冲区并直接从磁盘读取数据。

请记住，不同类型的内核、系统、磁盘控制器、系统设置、fs 等的结果可能不同。

补充：

 [debugfs] 
[root@dhcppc3 test]# debugfs /dev/sda1 
debugfs 1.39 (29-May-2006)
debugfs:  cd test
debugfs:  stat test.xml
Inode: 24102   Type: regular    Mode:  0644   Flags: 0x0   Generation: 3385884179
User:     0   Group:     0   Size: 4
File ACL: 0    Directory ACL: 0
Links: 1   Blockcount: 2
Fragment:  Address: 0    Number: 0    Size: 0
ctime: 0x543274bf -- Mon Oct  6 06:53:51 2014
atime: 0x543274be -- Mon Oct  6 06:53:50 2014
mtime: 0x543274bf -- Mon Oct  6 06:53:51 2014
BLOCKS:
(0):29935
TOTAL: 1

debugfs:

【讨论】：

这是很好的信息，关于数据在“原始”文件和副本之间存储在磁盘上的方式，我开始得出类似的结论。我将试一试，看看这是否可能归结为 Perl 和 Python 默认从目录树读取的不同顺序。据我所知，即使我在同一目录上同时测试 python 和 perl，结果也会有所不同，无论它是原始的还是复制的。 debugfs 也很有用，这对我来说是一个新工具 :-)
Yes:)，那么你就可以玩转：Python/Perl 如何读取文件（按什么顺序）以及文件如何放在磁盘上。
你是如何获得 BLOCKS 输出的，我正在努力从 debugfs has found blocks 命令中获得类似的结果，但无法获得像上面这样的良好输出。
所以我摆弄了排序顺序并认为订单文件已创建并最终在 50K 文件中得到以下内容。 Perl（默认顺序）13s，Python（默认顺序）4m 48s，Python（自然排序，所以1.xml，2.xml）11s。很明显，考虑创建顺序和读取文件的顺序非常重要，我从来没有意识到它会产生如此大的不同，尽管非常感谢这个线程上的所有帮助。
我在帖子中添加了如何通过 debugfs 进行调试（添加部分）