为什么FWRITE libc的功能比系统调用write函数更快？ [英] Why the fwrite libc function is faster than the syscall write function?

问题描述

提供相同的节目其内容随机生成的输入文件，并回读给输出相同的字符串后。唯一的区别是，在一边，我提供的读写从Linux系统调用的方法，并在另一边我用FREAD / FWRITE。

计时我的应用程序，在尺寸的为10Mb输入和呼应它到/ dev / null的，并确保该文件没有缓存，我发现，libc中的FWRITE使用非常小的缓冲区（当快被大规模的情况下，1个字节）。

下面是我的时间输出，使用FWRITE：

 真正0m0.948s
用户0m0.780s
SYS 0m0.012s
 

和使用系统调用写：

 真正0m8.607s
用户0m0.972s
SYS 0m7.624s
 

这是我能想到的唯一的可能就是内部的libc已经是我的缓冲输入。可惜我找不到网络上的很多信息，所以也许这里的高手们可以帮助我。

解决方案

  

我的计时与应用程序的输入
  10MB的大小和它的回响
  的/ dev / null的，并确保在该文件中
  没有缓存，我发现，libc中的
  frwite更快通过大规模的时候
  使用非常小的缓冲区（1字节
  情况）。

FWRITE 适用于流，这是缓冲。因此，许多小的缓冲区会更快，因为直到缓冲区填满它不会运行昂贵的系统调用（或者你冲洗，或关闭流）。在另一方面，小缓冲区发送到写将运行一个昂贵的系统调用的每个缓冲区的 - 这就是你失去的速度。随着1024字节流缓冲区，写1个字节的缓冲区，你看10​​24 写调用每个千字节的，而不是1024 FWRITE 来电转成一个写 - ？看到区别

有关大缓冲区的差异会很小，因为会有缓冲较少，因此之间的系统调用更加一致的数 FWRITE 和写。

在换句话说，的fwrite（3）只是一个库例程输出收集成块，然后调用写（2）。现在，写（2），是一个系统调用的其中的陷入内核的。这就是在I / O实际情况。有一些开销简单地调用到内核，再有就是它需要真正写东西的时间。如果你使用大缓冲区，你会发现，写（2）更快，因为它最终无论如何都要调用，如果你每FWRITE写一次或多次，然后和fwrite缓冲开销就是：更多的开销

如果您想了解更多的话，你可以看看这文件，这也解释了标准的I / O流。

After providing the same program which reads a random generated input file and echoes the same string it read to an output. The only difference is that on one side I'm providing the read and write methods from linux syscalls, and on the other side I'm using fread/fwrite.

Timing my application with an input of 10Mb in size and echoing it to /dev/null, and making sure the file is not cached, I've found that libc's fwrite is faster by a LARGE scale when using very small buffers (1 byte in case).

Here is my output from time, using fwrite:

real    0m0.948s
user    0m0.780s
sys     0m0.012s

And using the syscall write:

real    0m8.607s
user    0m0.972s
sys     0m7.624s

The only possibility that I can think of is that internally libc is already buffering my input... Unfortunately I couldn't find that much information around the web, so maybe the gurus here could help me out.

解决方案

Timing my application with an input of 10Mb in size and echoing it to /dev/null, and making sure the file in not cached, I've found that libc's frwite is faster by a LARGE scale when using very small buffers (1 byte in case).

fwrite works on streams, which are buffered. Therefore many small buffers will be faster because it won't run a costly system call until the buffer fills up (or you flush it or close the stream). On the other hand, small buffers being sent to write will run a costly system call for each buffer - that's where you're losing the speed. With a 1024 byte stream buffer, and writing 1 byte buffers, you're looking at 1024 write calls for each kilobyte, rather than 1024 fwrite calls turning into one write - see the difference?

For big buffers the difference will be small, because there will be less buffering, and therefore a more consistent number of system calls between fwrite and write.

In other words, fwrite(3) is just a library routine that collects up output into chunks, and then calls write(2). Now, write(2), is a system call which traps into the kernel. That's where the I/O actually happens. There is some overhead for simply calling into the kernel, and then there is the time it takes to actually write something. If you use large buffers, you will find that write(2) is faster because it eventually has to be called anyway, and if you are writing one or more times per fwrite then the fwrite buffering overhead is just that: more overhead.

If you want to read more about it, you can have a look at this document, which explains standard I/O streams.

这篇关于为什么FWRITE libc的功能比系统调用write函数更快？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！