为什么glibc的sscanf比Linux上的fscanf慢得多?

Ker*_* SB 18 c performance glibc scanf

我在x86_64 Linux上使用GCC 4.8和glibc 2.19.

在为不同的问题使用不同的输入法时,我比较fscanfsscanf.具体来说,我要fscanf直接使用标准输入:

char s[128]; int n;

while (fscanf(stdin, "%127s %d", s, &n) == 2) { }
Run Code Online (Sandbox Code Playgroud)

或者我首先将整个输入读入缓冲区然后遍历缓冲区sscanf.(将所有内容读入缓冲区需要花费很少的时间.)

char s[128]; int n;
char const * p = my_data;

for (int b; sscanf(p, "%127s %d%n", s, &n, &b) == 2; p += b) { }
Run Code Online (Sandbox Code Playgroud)

令我惊讶的是,该fscanf版本是大大加快.例如,处理数以万计的行fscanf需要这么长时间:

10000       0.003927487 seconds time elapsed
20000       0.006860206 seconds time elapsed
30000       0.007933329 seconds time elapsed
40000       0.012881912 seconds time elapsed
50000       0.013516816 seconds time elapsed
60000       0.015670432 seconds time elapsed
70000       0.017393129 seconds time elapsed
80000       0.019837480 seconds time elapsed
90000       0.023925753 seconds time elapsed
Run Code Online (Sandbox Code Playgroud)

现在同样的sscanf:

10000       0.035864643 seconds time elapsed
20000       0.127150772 seconds time elapsed
30000       0.319828373 seconds time elapsed
40000       0.611551668 seconds time elapsed
50000       0.919187459 seconds time elapsed
60000       1.327831544 seconds time elapsed
70000       1.809843039 seconds time elapsed
80000       2.354809588 seconds time elapsed
90000       2.970678416 seconds time elapsed
Run Code Online (Sandbox Code Playgroud)

我正在使用Google perf工具来衡量这一点.例如,对于50000行,fscanf代码需要大约50M周期,sscanf代码大约需要3300M周期.所以我用perf record/ 破坏了热门网站perf report.用fscanf:

 35.26%  xf  libc-2.19.so         [.] _IO_vfscanf
 23.91%  xf  [kernel.kallsyms]    [k] 0xffffffff8104f45a
  8.93%  xf  libc-2.19.so         [.] _int_malloc
Run Code Online (Sandbox Code Playgroud)

并与sscanf:

 98.22%  xs  libc-2.19.so         [.] rawmemchr
  0.68%  xs  libc-2.19.so         [.] _IO_vfscanf
  0.38%  xs  [kernel.kallsyms]    [k] 0xffffffff8104f45a
Run Code Online (Sandbox Code Playgroud)

所以几乎所有的时间都用sscanf在了rawmemchr!为什么是这样?fscanf代码如何避免这种代价?

我试图寻找这个,但我能想到的最好的是关于锁定realloc电话的讨论,我认为这不适用于此.我也在想fscanf有更好的内存局部性(反复使用相同的缓冲区),但这不能产生如此大的差异.

有没有人对这种奇怪的差异有任何见解?

nos*_*nos 18

sscanf()将传入的字符串转换_IO_FILE*为使字符串看起来像"文件".这是相同的内部_IO_vfscanf()可以用于字符串和文件*.

但是,作为转换的一部分,在_IO_str_init_static_internal()函数中完成,它__rawmemchr (ptr, '\0');在输入字符串上调用了一个strlen()调用.这种转换是在每次调用sscanf()时完成的,因为你的输入缓冲区相当大,所以它会花费相当多的时间来计算输入字符串的长度.

使用fmemopen()从输入字符串创建FILE*并使用fscanf()可能是另一种选择.

  • 我建议提交针对glibc的错误报告.这个问题肯定可以通过使`sscanf`提供的虚拟`FILE`使用不需要提前了解字符串长度的自定义操作来解决.实际上我们在musl libc中的实现避免了这个问题,所以我知道它是可能的.:-) (5认同)

Mic*_*urr 7

sscanf()在执行任何其他操作之前,看起来glibc会扫描源字符串的长度.

sscanf()(in stdio-common/sscanf.c)本质上是对_IO_vsscanf()(in libio/iovsscanf.c)调用的包装器.首先要做的事情之一_IO_vsscanf()_IO_strfile通过调用_IO_str_init_static_internal()(in libio/strops.c)来初始化它自己的结构,如果没有提供它,它会计算字符串的长度.